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ABSTRACT 


All Naval dental treatment facilities (DTP) worldwide are 
required to submit monthly reports containing dental records 
of treatments provided and overall dental readiness to COMNAV- 
MEDCOM, in Washington, D.C. These reporting requirements are 
standardized to meet not only the requirements of the Navy, 
but also as input to the DOD mandated Medical Expense and Per¬ 
formance System (MEPRS). At many commands, this data collec¬ 
tion storage and reporting effort is currently performed 
manually, adding unnecessary additional administrative burden. 

This thesis develops a computerized database system 
providing increased accuracy and productivity, and capable of 
meeting the NAVMED reporting requirements. The Dental Infor¬ 
mation Retrieval System (DIRS) developed will record all 
treatments provided for each beneficiary category described in 
NAVMEDCOMINST 6600.IB, and will facilitate internal and 
external daily, weekly, monthly and annual reporting require¬ 
ments. An important design consideration is providing the 
DIRS developed with the requisite capabilities specified by 
the "DTP'S, without imposing additional hardware requirements. 

NAVDENCLINIC Long Beach, Ca., is the sponsoring activity 
for the DIRS, and will serve as the test site for system 
implementation. If the system is successful. Director of 






Dental Services, San Diego, Ca., has indicated interest in the 
system as a Navy-wide managerial tool. 
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I. 


INTRODUCTION 


A. BACKGROUND 

Naval Medical Command (NAVMEDCOM), Washington, D.C., is 
chartered to provide general and specialized health and dental 
care for active duty members of the Navy and Marine Corps at 
ships, posts, and stations worldwide. When available, this 
service extends to other eligible beneficiaries; members of 
other Federal Uniformed Services, retirees and their 
dependents, and dependents of active duty personnel. 

To meet requirements for internal and external budgeting, 
performance, training and readiness reporting, NAVMEDCOM tasks 
all activities providing dental care to submit Dental 
Information Retrieval System (DIRS) reports as prescribed in 
NAVMEDCOMTMST 6600.IB. This instruction provides guidance for 
submission of monthly reports from subordinate Dental 
Treatment Facilities (DTF) or Regional Headquarters to 
COMNAVMEDCOM in Washington D.C. Procedures lor leporting 
dental readiness are explicitly specified in the instruction, 
including outlines of treatment codes and the associated 
composite time values required for producing mandated monthly 
reports used as input to the Medical Expense and Performance 
System (MEPRS). MEPRS is a Department of Defense (DOD) 
mandated report that is prepared at NAVMEDCOM from input 






provided by subordinate medical and dental commands in the 
Department of the Navy (DON). 

Commanding officers and heads of dental departments at all 
activities providing dental care are responsible for 
submission of NAVMED 6600/8, the DIRS monthly Treatment 
Report. If personnel from more than one DTF are combined 
under a single command, then the senior dental officer at the 
headquarters level is responsible for compliance with the 
NAVMEDCOMINST directives and for the accurate treatment totals 
assigned to the corresponding provider. 

The preface to NAVMEDCOMINST 6600.IB states: 

The (COMNAVMEDCOM) DIRS is a computer-based collection and 
information processing system designed to collect data on 
the treatment provided to all eligible beneficiaries. The 
information provided by the DIRS will assist Dental Corps 
managers at all levels in accomplishing accurate and 
realistic planning for resource requirements, allocation, 
and use. [Ref. 1] 

Submission of the NAVMED 6600/8 and other dental reports 
follow the dental command hierarchy depicted in Figure 1.1. 

At NAVMEDCOM level, the DIRS is a computer-based system. 
However, the DIRS Treatment Report (NAVMED 6600/8), the 
requisite monthly feeder report from all DTF's, is a ten-pitch 
optical character recognition (OCR) form that presently may 
only be prepared manually. It is this mandated submission 
format and data collection requirement that has created a need 
for the development of computerized DIRS at the lower echelon 
DTF's. Although some commands have proceeded with in-house 
development of automated DIRS, none have been successful in 
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Figure 1.1 Organization Chart 

providing adequately for data integrity issues such as 
redundancy, consistency and concurrency. Most systems were 
created by non-ADP personnel with little or no formal training 
in database design issues, hence much of the desired 
functionality, especially in the areas of updates to the 
database and supporting documentation, were inadequately 
addressed or exhibited poor design. 

The mandated monthly NAVMED 6600/8 report resulting from 
either a manual or computerized DIRS is transcribed via OCR-A 
capable typewriter, and the resulting original form is mailed 
to COMNAVMEDCOM. Reports submitted for a given month are to 
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be received no later than the 15th day of the following month. 
At NAVMEDCOM in Washington, D.C., these reports are entered 
into the DIRS via OCR reader. Any failure in the ability of 
the OCR reader to assimilate the correct data, caused by 
ordinary and extraordinary events such as folds, staple holes, 
stains, rips, ink too light, misaligned characters, etc., 
requires report resubmission by the corresponding DTF. The 
weakness of such a system is obvious, and represents a major 
bottleneck to the efficiency and success of the reporting 
system. 

B. STATEMENT OF PROBLEM 

The problem with DIRS is twofold: The first problem is 
that manual systems require assignment of a significant 
collateral duty to a dental technician (DT) to gather, sort, 
compute and report dental treatment information submitted by 
each provider. Each individual treatment is assigned a 
composite time or weighted point value. The time savings 
offered by an automated system, would allow better use of the 
DT assigned to this task in more critical duties related to 
actual patient care. The second problem is that existing 
computerized DIRS applications are command dependent; lacking 
standardization in quality and capabilities and tailored only 
for a specific command. The present computerized DIRS 
application is also dependent on a particular database 
package. For example, any update function must be achieved 
via the specific DBMS used to develop the application program. 
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This dependency is costly in the sense that given a DIRS 
system programmed using a commercial database package such as 
ORACLE or INGRES, that specific package must first be 
installed on the personal computer (PC) used for DIRS 
reporting. The personnel operating such a system must be 
familiar with the nuances and features of the particular 
database package, which complicates the training on the 
system. 

A solution to these problems was hoped to be found in the 
Dental Management Information System (DENMIS), a proposed 
tri-service system, which had its first module (patient 
appointment module) tested last year at Headquarters NDC Long 
Beach, Ca., with unsatisfactory results. 

Further development effort on the DENMIS and on individual 
modules such as DIRS was halted with the original contractor. 
The DENMIS contract was relet through NARDAC, Washington, 
D.C., with proposed testing at 27 sites in 1990. According 
to the contract firm, the proposed DENMIS will require an 
80386-based personal computer to function properly. This 
particular specification tends to limit the utility of the 
program developed, for some Dental Treatment Facilities, 
especially small or deployed DTF's currently lack this 
additional specified hardware requirement. Recent information 
indicates that the contracted DENMIS system will not include 
a DIRS module as a result of insufficient funding. [Ref. 2] 
The current thesis work is not intended to replace DENMIS, but 
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to provide a quality DIRS module for NAVDENCLINIC Long Beach, 
Ca., and the Director of Dental Services, San Diego, Ca., 
until possible future delivery of a contractor-developed DIRS. 

The identified requirement for a computerized DIRS coupled 
with the uncertain future of DENMIS, have generated renewed 
interest in the development of a proposed flexible PC-based 
DIRS system that will aid lower echelon DTE's in meeting the 
stringent reporting requirements mandated by COMNAVMEDCOM. 

C. SCOPE 

The proposed Dental Information Retrieval System (DIRS) is 
intended to provide a stand-alone, compiled, non-command 
dependent relational database system and associated 
applications program. The system is necessary to support 
administration, documentation and accounting of patient 
treatment provided by dental officers and dental laboratory 
technicians. The software system development life cycle 
(SDLC) will be used to develop a working DIRS (to include: 
system analysis, design, development, documentation in the 
form of user's manual, implementation and training). Research 
issues are listed below: 

Identification of user requirements. 

Examine present instructions or guidelines for DIRS. 

Determine if it is feasible to develop a DIRS's system 
that is not dependent on an external DBMS; i.e., dBASE 
IV, dBASE III PLUS, ORACLE or any other off-the-shelf 
DBMS. 
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Determine if a DIRS's system can be developed that is 
command independent, i.e., Unit Identification and/or 
provider(s) code not hardcoded in source code. 

Develop a system to support multiple clinics, yet account 
for each DTP separately. 

- Execute critical file back-up without requiring access to 
an external DBMS. 

Organize, sort, and index files without access to an 
external DBMS. 

The goal of this development effort is an imbedded DBMS in 
the compiled DIRS application that can be used on any IBM PC 
compatible system with a minimum 20 megabyte hard disk 
commonly found throughout the U.S. Navy dental community. 
Success with this project would reduce unnecessary 
off-the-shelf database purchases, reduce many long hours of 
manual data collection and manipulation to produce mandated 
reports. Automation will improve accountability of dental 
productivity, and will provide better utilization of dental 
personnel. 

D. METHODOLOGY 

Prior to development of a computerized DIRS, the current 
system must be analyzed and the needs of system users 
identified. A four-phase process of system analysis will be 
followed: study, requirements definition, design and 

implementation phase. 

In the study phase, the relative characteristics, 
capabilities and deficiencies of the current system are 
examined and documented. 


7 




Specific objectives in gaining a thorough understanding of 
the system are: 

Identify system users and others affected by the current 
system. 

Identify deviations and deficiencies between goals, 
purpose, policies and objectives of the present system, 
and actual system performance. 

Identify functions of the current system that provide 
adequate support to the mission and users. 

Map the components of the present system, and analyze the 
required interaction. 

In rec[uirements definition, the second phase of systems 

analysis, the following two goals were identified: 

Identification of required objects and their structure. 

Identification of functional components for each 
application with access to the database. 

In design phase, the third phase of systems analysis, the 

specific actions listed below must occur: 

Transformation of objects into a relational design. 

Developing the functional requirements into application 
design. This includes detailed formats for forms, 
reports, menus, and logic for programs. 

Implementation is the actual transformation of relations, 
and pseudo-code developed during design phase into files and 
working applications. In this phase, actual coding, testing, 
installation, and training of users will occur. 

E. FEASIBILITY 

1. Cost 


The developmental cost of the Dental Information 
Retrieval System is limited to the personal time and effort of 
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the thesis participants. Equipment needed for system 
development is now on hand either at the Naval Postgraduate 
school, Monterey, Ca., or in the personal possession of the 
thesis team. Implementation and training at the test site is 
not expected to exceed two working days. The sponsoring 
activity; Headquarters Naval Dental Center (NDC), Long Beach, 
Ca. , has offered financial support for the travel, 
implementation, and training costs associated with this 
project. Extensive use of pull-down menus, simple easy-to- 
follow dialogue, and a comprehensive DIRS user's manual will 
simplify training. 

2. Technical 

The design architecture proposed will allow the 
individual DTP to store one year of provider's treatment 
information for the entire command, on the DIRS. The minimum 
hardware requirement is stated below: 

An IBM-AT compatible computer with a minimum 64OK RAM 

memory. 

20 megabyte capacity hard disk. 

MS-DOS version 3.0 or later release. 

An OCR 10 pitch printer. 

3. Schedule 

The proposed system will be available as a complete 
working application including documentation, by March of 1990. 
It should be possible to develop and test DIRS in one to two 
months. Installation and user training is not expected to 
exceed two to three days. 
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II. USER REQUIREMENTS 


A. PRESENT SYSTEM 

Each dental command has a DIRS to meet reporting 
requirements mandated by COMNAVMEDCOM. The monthly submission 
by fleet DTF's of the NAVMED 6600/8 (DIRS Treatment Report), 
is the culmination of a daily manual collection and 
categorization effort by each provider and supporting DT at 
each DTE. 

As depicted in Figure 2.1, data origination occurs as a 
dental provider (dentist, dental technician, etc.), performs 
a treatment or multiple treatments on a patient belonging to 
one of nine beneficiary category codes (see Figure 2.2). Each 
provider in a DTF will record this information for every 
patient attended during the reporting period (in this example, 
a single day) on a Daily Count Sheet. The dental technician 
assigned responsibility for aggregating this data insures a 
corresponding three-digit provider code is assigned to the 
respective provider treatment counts prior to producing a 
daily NAVMED 6600/11 (Appendix I). Each day treatments are 
performed requires a NAVMED 6600/11 for inclusion in the 
monthly summation of provider totals; NAVMED 6600/8 (Appendix 
J). It is this report that must be prepared in OCR format for 
eventual submission to COMNAVMEDCOM, Washington, D.C., after 
routing through the respective chain of command. Branch 
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clinics operating under a headquarter’s clinic are required to 
submit their data for inclusion in an aggregate headquarters 
NAVMED 6600/8 report. Independent DTFs submit their report 



PMOVIOEA 1 PAOVIDER t fROEIDER N 

MONTHUr TOTAL MONTHLY TOTAL MONTHLY TOTAL 



Figure 2.1 Current Manual DIRS Data Flow 
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directly to COMNAVMEDCOM. In both cases, report receipt in 
Washington D.C. is required no later than 15 days following 
conclusion of the reporting period. User interviews indicate 
that report preparation may require several days, especially 
at headquarters commands. Reports must be tabulated by 
individual provider, beneficiary category codes, and coded 
treatments completed. Each beneficiary code listed in Figure 
2.2 must have individual accounting of treatments performed, 
for each provider assigned to a DTF. 


BENEFjCIARY CODES: 

01 - Active Duty. U.S. Navy 

02 - Active Duty. U.S. Marine Corps 

05 - Active Duty, Other Services 

08 - Recruit, U.S. Navy or Marine Corps 

09 - Dependents of Active Duty 

U.S. Uniformed Services Personnei 

10 - Dependents of Retired or Deceased 

U.S. Uniformed Services Personnei 

11 - Retired Uniformed Services Personnei 

12 - Other Personnel not listed in Codes 

01 through 11 and 13 

13 - Dependent Children, 

_ (17 & under and unmarried) _ 

Figure 2.2 Beneficiary Code Table 

Reporting preparation difficulties are compounded by the 
vast number of most frequently performed clinical services 
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treatment codes (over 280), and over 82 laboratory services 
codes. "The clinical services treatment code weight factors 
are based on time values and are termed composite time values 
(CTV). A CTV of 1 equals 17 minutes." [Ref. 1] Similarly, 
each laboratory services code is assigned a composite lab 
value (CIiV) . One CLV is assigned a six minute value. A wide 
variance in possible point value complicates reporting; in 
clinical services, for example, blood pressure recording is 
assigned a CTV of .3, while fitting for a partial denture with 
precision attachments is assessed a 25.9 CTV. For lab 
services the variance is greater; from 1 CLV for issuing 
teeth, to an assigned CLV of 220 for creation of an Andrews 
Bridge (an entire dental restoration). This information is 
valuable as a management tool for examination of historical 
trends, administration and resource allocation decisions, and 
in comparison/analysis of various ratios; i.e., total CTV's 
divided by number of providers, CLV’s by available time, etc. 

The submission to COMNAVMEDCOM in the form of NAVMED 
6600/8 is a monthly compilation of Daily Treatment Records 
from all providers at a given DTF. The Unit Identification 
Code (UIC) identifies the activity submitting the report. 
NAVMEDCOMINST 6600.IB states that each Dental Treatment 
Facility must submit the OCR format NAVMED 6600/8 via priority 
mail to arrive at COMNAVMEDCOM "not later than the 15th day 
of the month following the month for which the treatment was 
provided." [Ref. 1] The instruction also directs that a copy 


13 







of the submission be mailed to the "appropriate geographic 
naval medical command (geographic NAVMEDCOM)." These mandated 
stipulations create time constraints that leave little or no 
time for the responsible headquarters command to review 
subordinate clinic's NAVMED 6600/8. 

While the current technology exists within the DON to 
expedite reporting system requirements, the rigid adherence to 
the OCR-A typewriter and carbonized form creates a reporting 
bottleneck causing needless delays and repetition. The time 
lost in preparing and submitting the NAVMED 6600/8 each month 
is valuable time that could be spent on patient care. The 
present system can support only one clinic and lacks the 
provision for data import to meet mandated reporting via their 
respective headquarters, in effect rendering each DTF an 
independent command. 

B. REQUIREMENTS DEFINITION 

The purpose of this phase is twofold. It defines data 
requirements (objects) that must be represented in the 
database and outlines functional requirements; (update, 
display, and control mechanisms) necessary to support the 
Dental Information Retrieval System. User requirements are 
the "blueprint" for database design. [Ref. 3] Accurate 
identification and representation of user requirements is 
critical to the success of the entire development effort. 

An object-oriented methodology will be used to define and 
further clarify actual user requirements. This methodology 
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includes the identification of objects, development of object 
views, and materialization of these views into applications. 
"An object is a named collection of properties that 
sufficiently describes an entity in the user's work 
environment." An entity is "a class of things that exist in 
the users business environment." [Ref. 3] 

1. Data Recmirements 

Objects necessary for inclusion in the database were 
identified by examining NAVMEDCOMINST 6600.IB, current manual 
DIRS data flow (Figure 2.1), and from personal interviews of 
dental technicians and dental managerial personnel. Through 
the processes described above, objects were identified and 
transformed into object diagrams (Appendix A) . 

a. Object Description 

In defining the requirements of a database 
application, it is important to identify and capture those 
objects that accurately describe the aspects of the user's 
work environment which the database is intended to model. 
Recall that "an object is a structure that represents an 
entity." [Ref. 3] Multi-valued properties are allowed to 
have more than one value, and may themselves be objects or 
non-object properties. "Object properties represent other 
objects" while "non-object properties represent descriptive 
characteristics"of objects. User's environment objects and 
properties identified are described below. Depictions of 
objects are accomplished through the use of object diagrams 
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(see Appendix A.) "An object diagram describes objects in the 
user's world and their relationship to one another." The 
seven boxes depicted in Appendix A each represent a single 
object. Listings inside each box contain all properties of 
that object. Note that some properties listed are portrayed 
in lowercase letters, while others are enclosed in small boxes 
and are written in uppercase letters. These properties are 
themselves other objects. For example, the PROPERTY 
"COMMAND" inside the box titled "STATS (HQ)" denotes that the 
object COMMAND is a property of the object STATS (HQ). The 
subscript "MV" beneath some of these boxes denotes that the 
property is multi-valued. 

The Provider Object represents individual 
personnel who provide direct and indirect patient care. A 
laboratory technician performing a procedure such as waxing a 
crown, is an example of indirect patient care. A dentist 
delivering the crown is an example of direct treatment. 
Individual rank, name, and duty status (active duty, reservist 
or contractor) are properties of this object. The multi¬ 
valued Daily object is also a property of the Provider object, 
relating the provider with the properties associated with the 
Daily object. 

The Treatment (DIRS Code) Object represents 
treatment codes, the military services-developed series of 
codes adopted from the American Dental Association (ADA) 
Council on Dental Care Programs. Each treatment is assigned 
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a unique identifying code, description of treatment, and a 
composite time value (CTV). There are approximately 300 
codes. Treatment codes are identified in full and can be 
found in NAVMEDCOMINST 6600.IB. The proposed DIRS will 
include the list of codes and their meaning, to eliminate the 
inconvenience of looking the information up in the 
NAVMEDCOMINST. 

The Command Object, which consists of the Unit 
Identification Code (UIC), the command name, and the MEPRS 
codes, identifies the submitting unit. The MEPRS code is also 
known as the UCA code, and is used only for NAVMEDCOM Naval 
Hospitals and Naval Dental Commands. The four digit code for 
each work center is required on each NAVMED 6600/8 submission, 
and delineates the type and location of dental procedures 
performed. The Command object also includes the multi-valued. 
Provider and Year objects. 

The Daily Object represents entries for a 
particular data entry session, that include each instance of 
an individual provider providing a treatment to a patient in 
one of the nine beneficiary categories. The NAVMEDCOMINST 
does not specify a requirement that daily treatment 
information be automated, but a hardcopy of the Daily 
treatment work sheets must be kept on-hand for two years. 

In order to support both headquarters and branch 
clinics, three additional objects have been identified. The 
responsible headquarter's command has indicated the desire to 
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maintain a year’s compilation of information on all its 
component commands. Each branch clinic must maintain data 
specific to their clinic for a year. Both commands want to 
store information for a period of one year, but neither 
command has large capacity ADP storage hardware. Both want 
the capability of retrieving data by month in the appropriate 
format stipulated in NAVMEDCOMINST 6600.IB. For these 
reasons, a Year Object, and Monthly Object are needed to track 
branch clinic information and a Stats (HQ) Object is needed to 
keep all statistical information on all its subordinate 
commands. A Unit Identification Code (UIC) entity is required 
to uniquely identify a specific DTF. The Year and Monthly 
objects are very similar in structure. Each object consists 
of information relevant to the treatment performed on a 
particular beneficiary category code, the provider performing 
treatment and provider status, and the calendar month the 
treatment was effected. Object definitions are provided in 
Appendix B. 

b. Domain Definitions 

In addition to identification of required objects, 
and user views of those objects, further clarification of user 
requirements is achieved through specification of domain 
definitions. A domain is defined as "a description of the 
allowed values of an attribute." [Ref. 3, p. 150] Domain 
definitions include both physical descriptions of allowable 
data values, and logical descriptions pertaining to attribute 
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meanings. The domain definitions specified are provided in 
Appendix C. 

2. Functional Requirements 
a. Data Flow Diagrams 

Using the object requirements identified in the 
previous section, and proceeding with the object-oriented 
methodology, a dataflow diagram (see Figure 2.3 or Appendix 
D) was developed depicting required actions on objects 
identified. 

A dataflow diagram portrays the business functions and their 
data interfaces. Dataflow diagrams can be used to identify 
applications and the data they use. Four symbols are used 
in a dataflow diagram. Internal system processes are shown 
in circles, while external processes are shown in 
rectangles. Data interfaces are illustrated with named 
arrows, and stored data, including the database, is shown 
between parallel horizontal lines. [Ref. 3] 

As depicted in Figure 2.3, update mechanisms (add, 
edit and delete) and display mechanisms are required for DIRS 
and PROVIDER woject. Daily transactions cannot be recorded 
unless valid DIRS or provider information is recorded in the 
database. This information is provided by either 
NAVMEDCOMINST 6600.IB or DTF managers. Both provider and DIRS 
treatment code are unique, only one provider may be assigned 
provider code 100 for example. For the same reason, only 
treatment code ”0120" may represent a periodic oral 
examination. The proposed system shall provide update 
mechanisms insuring that duplicate records will not be created 
for those objects. Management assigns provider codes to new 
p:.oviders reporting onboard. To preserve data integrity, a 
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DATA FLOW DIAGRAM 



Figure 2.3 DIRS Data Flow 
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current provider listing will be generated for management 
review and to assist them in assigning provider codes to new 
personnel. 

The COMMAND object will be created only once upon 
initial installation of the proposed system. Command and 
MEPRS information are derived from COMNAVMEDCOMINST 6600.IB 
and DTF management. This object itself serves as a control 
mechanism. Users will only be authorized to access commands 
specified in this object. 

The heart of the required application is the 
creation and update mechanisms for the DAILY object. For it 
is through these mechanisms that the MONTHLY and YEARLY 
objects are updated. It will be the responsibility of the 
data administrator or data entry clerk to input provider work 
information which will update the DAILY, MONTHLY, and YEARLY 
objects. Appendix E delineates update, display and control 
mechanisms for each object described above. 

A STATS (HQ) object is created and updated through 
monthly and yearly information submitted by subordinate 
commands. A headquarters database must be maintained for a 
minimum of one year, consisting of the aggregate provider 
production information for each subordinate command. This 
object will provide management with the central depository to 
meet internal and external reporting requirements. The 
dataflow diagram presented in Figure 2.4 represents these 
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actions. Appendix E delineates update, display and control 
mechanisms for the STATS (HQ) object. 



Figure 2.4 STATS (HQ) Data Flow 

b. External Control 

External processes will augment database control. 
Access to the system for display of information will be 
controlled externally by the user command limiting physical 
access to the computer equipment to appropriate personnel. It 
will be left to physical security procedures to control 
routine access to the system's information display 
capabilities. Similarly, external processes will be used to 


22 










help regulate database updates. The user's manual (Appendix 
K) will provide structured guidelines for system use including 
data update procedures. 

c. Other Requirements 

During the interview process, several problems 
were identified. Data entry may not be accomplished on a 
daily basis. Provider's daily work sheets may be totalled and 
submitted at the end of the work week. Even if the provider's 
work sheet is submitted daily, the technician entering DIRS 
information may not have sufficient time to input data until 
the next day or even several days later. The DIRS must be 
flexible enough to handle this type of erratic schedule of 
data input. The DAILY object is needed to verify that data 
entered corresponds to the data reported on the provider's 
work sheet. 

Due to data storage limitations, the structure of 
the proposed system needs to offer several additional 
capabilities to users; file size grows only as required by the 
number of actual instances of treatments provided, not by 
arbitrary structure based on all possible treatments, per all 
beneficiary categories for each provider. An application with 
relations structured in this manner would soon exhaust 
available data storage capacities unless frequently purged. 
An efficient database design shall allow treatment instances 
to be updated and totalled in year-to-date totals rather than 
adding an additional record, yet still provide data extraction 
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capabilities for internal and external reporting. Appendix H 
contains examples of sample reports. 

The seven objects identified earlier are required 
in the structure of the proposed DIRS to meet the following 
requirements: 

The system must provide update mechanisms. 

Utility functions must be incorporated into the system to 
provide easy file backup and file organization such as 
indexing. 

The system dialogue must be easy for non-ADP personnel to 
follow and use. 

The system must have the capability of exporting 
requested information to floppy disk and at the 
headquarters level, to import branch clinic data to the 
Headquarters database. 

Several reports have been requested by the 
sponsoring activity. Headquarters must be capable of 
generating the required branch clinic OCR monthly report 
directly onto NAVMED 6600/11. Annual treatment reports 
similar in format to the monthly report shall be printed on 
request. Summaries and full Providers' performance reports 
also shall be available on request. Individual provider 
reports shall be generated monthly and submitted to the 
corresponding provider for his or her own personal performance 
information. 

An additional requirement identified by the 
sponsoring activity, as discussed previously, is support for 
multiple DTP'S under one command. During user interviews, it 
was determined that the proposed DIRS must be capable of 
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supporting up to nine DTF's under a single Headquarters 
command. Further, with multiple DTF's, the possible variety 
of hardware configurations requires that the proposed DIRS be 
generalized or "generic" to support the varied functions and 
requirements of a specific DTF. Though it may not always be 
the case in systems analysis and design, in this instance, the 
users' view of the objects to be captured by the DIRS, 
coincides closely with the actual application functional 
requirements used to model the users' view of the system. 

The computerized DIRS proposed and developed in 
the scope of this thesis will meet the reporting requirements 
of a Headquarters Clinic with up to nine subordinate DTF's. 
Through the user-interview process and dental clinic command 
structure review, the provision to support up to nine DTF's in 
the proposed program was identified to allow future expansion 
of the program in the event of dental command reorganization, 
without requiring modification of the database structure. 
Currently, NAVDENCLINIC Long Beach, Ca. , is one of the largest 
DTF Headquarters commands with five subordinate DTF's. 

In addition to the required features, the proposed 
system will allow subordinate units to report their monthly 
totals via either modem or "floppy" medium to their 
Headquarters Clinic. At the Headquarters level in the 
proposed DIRS, the input of the subordinate DTF's will be 
combined to generate the requisite NAVMED 6600/8 for 
submission to COMNAVMEDCOM. The proposed DIRS offers the 
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elimination of much of the manual handling and transcribing of 
daily count sheets, and offers accurate computerized 
completion of the OCR-A NAVMED 6600/8. 

Update, Display and Control Mechanisms required 
for the DIRS may be found in Appendix E. 
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III. SYSTEM DESIGN 


The third phase of the systems analysis process is system 
design. In this phase, the basis for the underlying structure 
of the database is delineated and built. The system design 
phase is sub-divided into the logical design phase and 
application design phase. The foundation established in the 
design phase is critical to successful development and 
maintenance of DIRS. The objective of logical database design 
is to translate the system blueprint identified in the 
requirements phase and to develop a set of relation diagrams, 
relation definitions, domain definitions and a list of 
constraints. 

A number of approaches to database design exist, and a 
brief discussion of some of the relevant issues includes the 
concepts of relations, keys, relationship constraints and 
normalization. The second phase of system design, application 
design, will describe the actual scope of DIRS, control 
mechanisms used, a description and depiction of the menu 
hierarchy. 

A. LOGICAL DATABASE DESIGN 

The relational database model will be used to develop the 
logical design of DIRS. This model translates the objects 
identified from analysis performed during the requirements 
phase into a relational design. The relation is logically 
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equivalent to a file, which contains rows and columns. A row 
in a relation table represents a record or tuple. Each column 
in a relation is termed an attribute or field. A process 
known as normalization is used to collect related data 
properties into robust well-designed relational (relation) 
tables. A well-structured design will "allow rows to be 
inserted, deleted, and modified without resulting in 
inconsistencies or errors in the stored data." [Ref. 3] 
Normalization serves to identify and eliminate these 
modification anomalies. Relations which correspond to DIRS 
are graphically depicted in Appendix F. 

1. Normalization 

Gathering or grouping of properties or data items into 
relations is an important aspect of database design. This 
process of "normalization" is used to eliminate database 
design weaknesses or flaws. These problems or "anomalies" as 
they are called, can result in inadvertent deletion of facts 
in a relation, or artificial and unintended restrictions on 
entity insertion. These modification or update anomalies are 
termed deletion anomalies or insertion anomalies respectively. 
The theoretical framework concerning proper database design is 
derived from early database design work of E.F. Codd who 
provided the definition of possible normal forms that 
relations may take. Normalization is the process by which we 
"troubleshoot" the database structure to identify and remove 
anomalies discovered. To do this, data items or properties 
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are grouped into relations as previously discussed. Object 
diagrams provided in Appendix A and relation diagrams provided 
in Appendix F depict groups of related properties upon which 
normalization is based. All relations are in at least first 
normal form. In the relations created within the scope of 
this thesis, each is at least in third normal form (3NF). "A 
relation is in third normal form if it is in second normal 
form and has no transitive dependencies.” [Ref. 3;p. 14 3] 
Second normal form is defined as a relation in which "all non¬ 
key attributes are dependent on all of the key." [Ref. 3: p. 
142] 

2. Keys 

"A key is a group of one or more attributes that 
uniquely identifies a row. Every relation has at least one 
key. Sometimes the key is one attribute." [Ref. 3:p. 139] 
In the example provided in Appendix F, the keys are 
underlined. In the PROVIDER object, the underlined attribute 
is Prov Code, a three digit code which serves to uniquely 
identify any provider in the system. It is possible that a 
group of attributes will be required to "functionally 
determine" (serve as a key to uniquely identify) other non-key 
attributes. 

3. Relations 

Relations are created by examining object diagrams 
(Appendix A) to determine relationships among objects 
(depicted in Appendix F) , then transforming these objects into 
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relations such as those described below. Depiction of an 
object may be relatively simple or may require the composition 
of several relations. Database objects (Appendix A), and 
relation diagrams (Appendix F) provide examples of such 
composition. A simple object contains only single-valued, 
non-object properties, and may be represented by a single 
relation. A composite object contains one or more non-object 
multivalued properties, and requires more than one relation 
for their representation. A compound object contains at least 
one object property, requiring translation of that object into 
a minimum of two relations. As an example, the MONTHLY object 
in Appendix A contains the object property COMMAND and the 
multivalued object DAILY. Each of the seven objects in 
Appendix A is a compound object, containing at least one other 
object property each depicted by its own relation as depicted 
in Appendix F. [Ref. 3] 

4. Relationships 

A binary relationship involves only two record types. 
Whereas an object was converted on a one-to-one basis into a 
relation (record type), relationships between those record 
types are not necessarily limited to one-to-one. In fact, in 
this database the majority of relationships are one-to-many. 
Referring again to the relation diagrams of Appendix F, a 
given STATS (HQ) may have multiple commands associated with 
it, as indicated by the "fork” on the command end of the 
connecting line. Similarly, a command can have many providers 
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and a provider will provide many treatments to many 
beneficiary category codes during the course of a daily 
(visit). 

There are a number of classifications pertaining to 
the degree of relationship that exits between objects, varying 
in complexity from no relationship between objects (0:0), to 
a many-to-many relationship (M:N). For example, in a one-to- 
one (1:1) relationship, one record is related to only one 
other record of another type. Additional explanation is 
required for notation used in Figure 3.1 and Appendix F, to 
indicate the type of relationship between record types. 
Beyond the "forked" end of the line which is used to indicate 
a "many" (as in one-to-many) , on the line connecting two 
objects or relations together, there may be either a circle or 
a bar. This notation is found on both ends of the line 
connecting the records, and is used to describe an optional or 
mandatory association between records. These associations are 
a type of relationship constraint. 

5. Relationship Constraints 

Relationship constraints such as those presented in a 
simplified version of DIRS Relationships are provided in 
Figure 3.1 below, with the detailed relationship structure 
provided in Figure 3.2 and Appendix F. If a relationship is 
mandatory, a bar will be found perpendicular to the opposite 
end of the line (side closest to the mandatory association). 
In the case of the COMMAND and PROVIDER objects in Figure 3.1, 
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Figure 3.1 DIRS Relationships 

it is mandatory that a COMMAND have a PROVIDER, and that a 
PROVIDER have a COMMAND. However, the circle found nearest 
STATS (HQ) on the line connecting COMMAND and STATS (HQ) 
indicates that while STATS HW must have a COMMAND associated 
with it, a COMMAND may have a (HQ) associated with it, but it 
is not mandatory, as COMMAND could stand alone. 

To accommodate the nuances of this reporting environment, 
and attain user functional requirements, the structure of 
database object relationships depicted in Figure 3.2 was 
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developed. Database relations identified remain identical to 
those represented above in Figure 3.1. The STATS (HQ) 
relation consists of the key attribute, UIC and each attribute 
belonging to COMMAND. UIC can serve as a key attribute for 
each relation because this five-number code is uniquely 
assigned to individual units. Relations containing other 
relations are identified by attribute names presented in all 
capital letters (with the exception of UIC). COMMAND, then, 
contains two other relations; PROVIDER and YEAR, each 
containing all attributes displayed within their respective 
boxes above, and in both appendices A and B. The Name 
attribute refers to Navy-assigned command plain language 
addresses, while MEPRS Code describes the four-digit work 
center code required on DOD dental reports. COMMAND has 
obvious relationships with PROVIDER and YEAR, as diagrammed by 
vertical lines connecting these relations, and more subtle 
relations through these two relations to all other relations. 
No object exists in isolation. It must be tied (related) to 
at leas~ one other object. These relations may be optional 
(circles) or mandatory (short horizontal line) as described 
earlier, and evidenced in Figure 3.2. 

YEAR, as defined by key relations COMMAND and MONTHLY, 
also contains an individual attribute for each beneficiary 
category code listed in Figure 2.2. 

In this manner, all treatments performed on members of a 
specific beneficiary code, for a particular month and at a 
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STATS (HQ) 



Figure 3.2 DIRS Relation Diagram 


specific command, are delineated and totalled separately. 
Similar structuring of attributes contained in both MONTHLY 
and DAILY, allows provisions for data extraction or 
combination, while always retaining identification of data 
origin. For example, PROVIDER contains the key attribute Prov 
Code, in addition to attributes; first name, last name, rank, 
duty status, and the DAILY obj'^ct. This structure means that 
if a provider performs a treatment on a specific day, each 
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attribute of TREATMENT; DIRS code, description of treatment, 
composite value and DAILY, is included in data specific to 
that provider. To identify a unique DAILY object instance; 
PROVIDER, TREATMENT and date, together seirve as keys. User 
requirements identified the necessity for storage of a year of 
DIRS data on disk at a time. To support this specification, 
the DAILY relation is designed as a temporary object, with 
data values added to update MONTHLY, at each convenient data 
entry session. Structured in this manner, all required data 
manipulation capabilities are supported with minimum disk 
storage overhead. Inclusion of daily beneficiary category 
totals to DAILY, permits accurate characterization and 
summation by category, stats (HQ), individual command, year, 
month, provider or treatment, for a particular instance or 
total to date. 

The structure described above offers several advantages to 
users; file size grows only as required by the number of 
actual instances of treatments provided, not by arbitrary 
structure based on all possible treatments, per all 
beneficiary categories for each provider. An application with 
relations structured in this manner would soon exhaust 
available data storage capacities unless frequently purged. 
Efficient database design allows treatment instances to be 
updated and totalled in year-to-date totals rather than adding 
an additional record, yet still provide data extraction 
capabilities for internal and external reporting. Several 
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reports are supported in addition to provisions for automatic 
formatting and generation of the required monthly NAVMED 
6600/8 using an OCR font printer. User desires for daily, 
monthly, annual, provider statistics and major treatment 
reports shall be supported options in the Report menu. 
Additional provisions for file import/export and maintenance 
shall be supported as described in the file utilities menu 
section. Support requests for possible expansion of up to 
nine subordinate DTFs under a single headquarters command is 
provided in accordance with user criteria. This support means 
that data from subordinate commands exported to a headquarters 
may be sub-totalled in as many as ten total categories. 
Additional features are discussed under menu hierarchy 
descriptions later in this chapter. 

B. APPLICATION DESIGN 

In following the object-oriented methodology, the 
application design phase will include determination of number 
and scope of applications, design control mechanisms for 
identified applications, and identify specific procedural 
logic. Additional considerations include; design 

materializations, database security and integrity. 

The data flow diagrams developed in the user requirements 
phase to help document flows of information, identify scope of 
required information needs, and describe required structure of 


36 





the organization, are used in the current phase to assist in 
the creation of the functional hierarchy. 

1. Application Control Mechanisms 

"An application is the user’s interface with the 
database." [Ref. 3] This interface must include the capacity 
for recognizing when data values entered are of an appropriate 
type and are within the intended range for the respective 
field. The users and developers consider extensive use of 
menus as the most appropriate user-system interaction method 
for a given application. On-screen templates (or masks, as 
previously discussed) will aid data entry process by 
restricting allowable data types (alphabetic, numeric, etc.) 
to the appropriate field. Pop-up help screens provide 
additional control in guiding users. Most DIRS on-screen 
messages are self-explanatory. Pre-established escape 
procedures, such as pressing any key on the initial or first 
blank field will allow users to abort an operation and return 
to a previous menu, or to exit the system entirely. An 
additional escape provision is available from within any level 
by pressing the escape key. 

Intuitive feel and simplicity of design allow not only 
shortened operator training time, but also permits the 
developers to limit deviations from the acceptable range of 
values for a given task or command. Consistent use of 
function keys to provide case sensitive help screens and 
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standardized conventions for interfacing with the application, 
also streamline user familiarity process. 

As previously stated, to accommodate the wide variety 
in computer literacy existing among potential system users, a 
menu-driven application was selected as the most appropriate 
application control mechanism. The next design step required 
the determination of menu hierarchy. Furthermore, it was 
determined that an object/action approach would best serve 
user needs. An object/action approach means "the highest- 
level menu offers the user a list of objects that might be 
processed, and lower-level menus enable the user to indicate 
the action to be taken on the selected object." [Ref. 3] 

An important design consideration for DIRS developed 
in the course of this thesis is not limiting the system to 
only one command. For example. Unit Identification Code 
(UIC), command name and UCA code must not be hardcoded in the 
program. This requirement will be accomplished upon initial 
installation of the system. A memory file will be created at 
that time containing the UIC, Command name, and related UCA 
codes for the appropriate command. Creation of this object as 
a memory file within random access memory (RAM) creates 
efficiency gains, saving multiple disk seek and access times. 
This object is frequently called as a visual aid in the form 
of a pop-up menu. As an example, a subordinate command is not 
required to reenter its UIC for each instance of DIRS data 
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input for a daily transaction, as object relation design 
results in automatic updates to related attributes. 

C. MENU HIERARCHY DESCRIPTxONS 

Menus used in the DIRS application were derived from an 
analysis of user recpiirements and data flow diagrams. Menus 
corresponding to these diagrams and structures are briefly 
described in the following section. Figure 3.3 depicts the 



menu structure hierarchy which provides graphic information 
pertaining to specific applications, objects, or tasks 
assigned to a block, module, or sub-module supported. 


39 





















1. Main Menu 


DIRS main menu shall offer system user options 
depicted in Figure 3.4. In every menu screen provided, an 
option may be selected by highlighting the desired selection 
or by typing the first letter of the desired option. The 
final option available on each menu screen is a provision for 
exiting to the next higher level menu, or in the case of the 
main menu, exiting DIRS to the operating system. 

As depicted in the following diagrams, each menu 
screen in the menu hierarchy exhibits common structure, 
consisting of three distinct parts. User information is 
provided in part A, with DTF command name, system name, 
current time and date, and screen number identified. Part B 
presents available menu options, part C provides option 
selection instructions and error message display. 


A 


B 


C 


Figure 3.4 Main Menu Screen 


Heading 


NAVAL DENTAL CLINIC, USN 13:17:17 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.0 


MAIN MENU 

INPUT DIRS DATA 
CHANGE DIRS CODES 
UPDATE PROVIDER CODES 
QUERIES 

FILE UTILITIES 
HEADQUARTERS ONLY 
QUIT 


USE UP AND DOWN CURSOR KEYS tl TO HIGHLIGHT ITEM AND 
PRESS<RETURN> 


Prompt & Status Box 
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To operate DIRS, users shall enter the first letter 
which corresponds to the item in the menu body to be selected, 
or move the arrow keys (ti) to highlight an option. All menus 
have a RETURN option to return to next higher menu in the 
hierarchy. 

a. Input DIRS Data 

The first screen that will appear when selecting 
option one (INPUT DIRS DATA) is displayed below (Figure 3.5). 
Enter "Y" (yes), if the displayed month is the desired month 
for data entry. Enter "N" (no) to select another month. When 
"N" is selected a window will appear displaying options that 
may be keyed in at the prompt (see open month screen below). 
The default month (open month on screen) is the current 
calendar month based on the computers system clock. 


NAVAL DENTAL CLINIC, USN 08:05:14 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.1.1 

OPEN MONTH IS JANUARY 

IS THIS CORRECT? Y/N 

Figure 3.5 Month Prompt Screen 

To select the correct month, the three letter 
abbreviation is entered at the prompt. For example, typing 
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JUN in the month selection screen will open that month for 
data entry. Once the desired month has been opened, the 
provider prompt screen will follow (Figure 3.6). 


NAVAL DENTAL CLINIC, USN 09:02:20 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.1.1 


JAN 

JUL 

FEB 

AUG 

MAR 

SEP 

APR 

OCT 

MAY 

NOV 

JUN 

DEC 


ENTER THREE LETTERS OF NEW MONTH: 


Figure 3.6 Month Selection Screen 


In selecting a provider, the provider code may be 
entered directly if the code is known, or by pressing the 
<HOME> key, an additional window with the valid provider codes 
assigned to the reporting command will pop up. From the 
available valid provider codes on screen, the corresponding 
number that matches the desired provider code may be entered. 
(See Figure 3.7 and Figure 3.8.) 

To select a valid provider, enter the matching 
number in the leftmost column, i.e.: entering number "1" 
would select provider 100; CDR Navy. The provider code may 
also be entered directly on the provider input screen. This 
method of provider data entry provides a method to check the 
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NAVAL DENTAL CLINIC, USN 08:18:58 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.1.1 


PROVIDER CODE; 


ENTER PROVIDER CODE OR PRESS <HOME> FOR HELP 


Figure 3.7 Provider Prompt Screen 


NAVAL DENTAL 

CLINIC, 

USN 

08:18:58 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.1.1 

PROVIDER 

CODE 

RANK 

NAME 

1. 

100 

CDR ■ 

NAVY, JOSEPH 

2. 

200 

LT 

NAVY, SON 

3 . 

300 

LT 

MESIAL, DECAY 

4. 

400 

CAPT 

TOOTH, DECAY 

5. 

455 

LT 

RESERVE, DENTIST 

6 • 

500 

CDR 

BUCKLE, PIT 

7. 

600 

LT 

LINGUAL, DISTAL 

8. 

700 

ADM 

DENTAL, SERVICE 

PRESS NUMBER 

OF ITEM, 

RETURN TO 

CONTINUE, OR "Q" TO QUIT 


Figure 3.8 Provider Selection Screen 


provider code file to validate a correct provider code for the 
reporting unit. Entering an erroneous code (a code not 
currently in the provider code file) results in an error 
message indicating that fact, and further prompts the user to 
enter another code. 

When the provider field is correctly entered, the 
screen displayed in Figure 3.9 will follow, prompting the user 
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to enter a valid treatment code. As previously discussed, to 
escape the DIRS entry routine, press <RETURN> at a blank DIRS 
field. 


NAVAL DENTAL CLINIC, USN 08:05:14 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.1.2 


Entering Data for Provider: CDR JOSEPH NAVY CODE: 100 


PRESS THE <HOME> KEY FOR A LIST OF DIRS CODES TO 
SELECT FROM. 

PRESS <RETURN> ON AN EMPTY FIELD TO RETURN TO THE 
MAIN MENU. 


ENTER DIRS CODE: 

Figure 3.9 DIRS Code Prompt 

Pressing the <HOME> key will display all valid 
DIRS codes (Figure 3.10). DIRS treatment code may also be 
entered directly on the DIRS prompt screen or the <HOME> key 
may be used to assist the user in the event that correct DIRS 
codes are unknown. This help function is not a mandatory 
input procedure. 


To select a DIRS treatment code, the corresponding 
number displayed in the leftmost column is selected by typing 
the appropriate number ("l"-"9”). Pressing the <Page Down> 













NAVAL DENTAL CLINIC, USN 

DENTAL INFORMATION RETRIEVAL SYSTEM 

08:05:14 
SCREEN # 

01/13/90 

1.1.2 

DIRS CODE 

DESCRIPTION 

WEIGHT 


1. 

0001 

POUR CAST 

2.0 


2. 

0002 

POUR CAST,FX 

4.0 


3 . 

0003 

BOX AND POUR 

5.0 


4 . 

0004 

IMP TRAY CUS 

4.0 


5. 

0005 

POUR ALT CAST 

5.0 


6. 

0006 

ARTIC. SIMPLE 

1.0 


7. 

0007 

ARTIC. SEMI 

1.5 


8. 

0008 

ARTIC. FULL 

2.0 


9. 

0009 

SOLDER/PER AREA 

4.0 


PRESS 

NUMBER 

OF ITEM, RETURN TO CONTINUE, OR "Q" 

TO QUIT 


Figure 3.10 DIRS Code Selection Screen 


or <Page Up> keys will scroll through the list to display 
other treatment codes. 

Data entry for an individual provider is 
accomplished using screen 1.1.3 depicted in Figure 3.11 by 
entering in the correct quantity of procedures completed in 
each dental beneficiary category. The <RETURN> key is used 
to move the cursor to the next field for data entry. The 
steps listed above are repeated until the user has completed 
data entry for a particular provider. Data entry error 
corrections are accomplished in a number of ways. The user is 
prompted with the following query at the bottom of screen 
1.1.3; "Is this data correct? Y/N." A negative response 
indicated by typing the "N" key, will allow the user to 
reenter the correct data. The user may overwrite the data 
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Figure 3.11 Daily Input Screen 


displayed on screen by moving the cursor using arrow keys to 
the correct field and reentering the correct quantity. 
Deletion and editing of values previously entered for a 
particular month is accomplished by selecting the desired 
month, provider, and treatment, and entering an appropriate 
negative value to either cancel or modify the monthly total 
for the selected record. To return to the main menu, the 
<RETURN> key is pressed with the cursor on a blank DIRS input 
field or typing "Q" when prompted from the help screen. When 
a month and provider have been selected, the user may continue 
adding new treatment data without the requirement of returning 
to the main menu for each instance. To enter data for another 
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provider, users must return to the main menu and select the 
desired month and treatments. The system shall default to the 
month of last data entry. Upon termination of a data entry 
session, a final query will prompt the user with the following 
message; "Do you wish to save this data? Y/N.” Selecting "N" 
will not save the data entered during the session. This 
particular feature is provided as another control mechanism, 
allowing the user to correct or terminate a data entry session 
without arbitrary input of inadequately screened or inaccurate 
data to the database. Selecting "Y" will automatically result 
in appropriate updates to the Daily, Monthly, and Yearly 
object files. Selection of "Y” will also result in the 
display of the following messages in the status box of the 
menu screen (part C) ; "Adding to Monthly Total" and "Adding 
to Yearly Total," informing the system user of action in 
progress. Again, listing command providers is provided as a 
convenience to the system user. 

b. Change DIRS Codes 

Selection 2 from the main menu (CHANGE DIRS CODES, 
Figure 3.12) is used to add, delete, or edit the DIRS (treat¬ 
ment) code file. Deleting means erasing of an existing code 
in the file. Editing means changing an existing code. When 
calling these functions, the procedure is similar to that of 
data entry described in the DIRS entry section. 
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NAVAL DENTAL CLINIC, USN 12:47:51 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.2 


DIRS CODES MENU 

ADD CODE 
EDIT CODE 
DELETE CODE 
LIST CODES 
RETURN TO MAIN MENU 


USE UP AND DOWN CURSOR KEYS ti TO HIGHLIGHT ITEM AND 
PRESS<RETURN> 


Figure 3.12 Update DIRS Codes Menu 


c. Update Provider Codes Menu 

The function of the Update Provider Codes menu 
(Figure 3.13) is similar to that described above for Change 
DIRS Codes. In this instance, rather than treatment codes. 


NAVAL DENTAL CLINIC, LONG BEACH, CA. 12:47:51 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.3 


PROVIDERS CODE MENU 

ADD CODE 
EDIT CODE 
DELETE CODE 
LIST CODES 
RETURN TO MAIN MENU 


USE UP AND DOWN CURSOR KEYS ti TO HIGHLIGHT ITEM AND 
PRESS<RETURN> 


Figure 3.13 Update Provider Codes Menu 
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update function and display function pertains to the treatment 
provider at a given command, 
d. Report Menu 

Branch clinic report menu (Figure 3.14) presents 
users with a number of options related to reporting of DIRS 
data by various chronological periods. Using the options 
available in this menu, the current total of treatments, 
treatments by provider, by command, etc., may be obtained. 
Additionally, a Major Treatment Report option is available as 
a menu selection for internal reporting purposes. Examples 
of each report selection are provided in Appendix H. 


NAVAL DENTAL CLINIC, LONG BEACH, CA. 12:49:38 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.4 


REPORT MENU 

DAILY REPORT 
MONTHLY REPORT 
ANNUAL REPORT 
PROVIDERS STATS. 

MAJOR TREATMENT REPORT 

RETURN TO MAIN MENU 


USE UP AND DOWN CURSOR KEYS tl TO HIGHLIGHT ITEM AND 
PRESS<RETURN> 


Figure 3.14 Branch Clinic Report Menu 







e. File Utilities Menu 


Menu screen in Figure 3.15 offers system users the 
ability to reindex, backup, transfer, and start a new 
recording year all from within the DIRS application. 
Providing these necessary functions from within the system as 
menu-driven options helps simplify the normally onerous and 
often neglected tasks such as backing up system data. 

The reindex data files option should be selected 
when the system shows signs of incorrect operation such as 
incorrectly assigned totals or data. As an example, reports 
may display zero work for all providers at a specified command 
for a given month. If this information is incorrect, using 
the reindex option will reassign the appropriate key field to 
their respective records. The reindex feature is often 
required in any database system. Power surges, improper file 
closing and hardware malfunctions are examples of possible 
causal factors for index distortion. The reindex option is 
provided to reestablish the proper links and pointers to 
correct the potential damage caused by these malfunctions. 
Simplicity inherent in the menu interaction format, should 
help increase the frequency of back-ups and maintenance of 
application data. 

The "Start New Year" option is provided when the 
users wish to begin recordkeeping functions for a new 
reporting year; either calendar, fiscal or other arbitrary 
selection. Failure to select this option when starting a new 
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NAVAL DENTAL CLINIC, LONG BEACH, CA. 13:50:16 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.5 


FILE UTILITIES 

REINDEX DATA FILES 
BACKUP DATA FILES 
START NEW YEAR 
TRANSFER DATA TO DISK 
RETURN TO MAIN MENU 


USE UP AND DOWN CURSOR KEYS ti TO HIGHLIGHT ITEM AND 
PRESS<RETURN> 

Figure 3.15 File Utilities Menu 

reporting period will result in overwritten data values and 
incorrect totals for the selected period. 

The "Transfer Data to Disk" option is selected to 
transfer data for a monthly reporting period to a "floppy 
disk" for subsequent export to the appropriate Headquarters 
command. Production of the OCR r'=‘port form may only be 
accomplished at the Headquarters level after import of the 
transfer files. 

Selection of transfer routine will transfer the 
working file to a floppy disk. The UIC window located in the 
lower right corner depicted in Figure 3.16 prompts the user 
to select a number; 1 through 5. The number "5" is 
representative of a Headquarters command with five subordinate 
DTFs. This number will reflect the actual number of DTFs 
supporting as few as one or as many as nine. If the system 
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NAVAL DENTAL 

CLINIC, USN 


13:51:59 11/10/89 

DENTAL 

INFORMATION RETRIEVAL SYSTEM SCREEN # 1.5.4 

ENTER 

UIC: 




ENTER 

MONTH 

OF REPORT: 


*** VALID UIC *** 




i.e. : 

1) 

00000 - HQ & NOWHERE 





2) 

55555 - PORT NEVERSAIL 





3) 

55511 - POINT HERE 





4) 

51515 - CHINA 





5) 

99999 -CO BEACH 





0) 

RETURN TO MAIN MENU 





SELECT (0-5)? 0 



Figure 3.16 Transfer Data to Disk Screen 


is being used at a branch clinic, only one UIC is displayed 
and selected. User input of the correct UIC is critical, 
because a UIC FIELD will be appended on the TRANS. FILE based 
on the UIC input. The TRANS. FILE is the database export file 
to be received by the corresponding Headquarters command. 
This routine will be selected when a subordinate DTF is 
required to submit data to headquarters. Regardless of 
transmission medium, the export routine must be selected to 
transfer all data to floppy disk, prior to submission of the 
updated monthly data requirements. The export procedure 
described above provides a necessary if subtle control 
mechanism ensuring that data back-ups are performed at least 
once a month. When properly labeled with the appropriate UIC, 
and month of transfer, the floppy disks containing the TRANS 
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database file (dbf) provide a convenient source of back-up 
data. The menu status box (part C) will provide a prompt to 
insert a floppy disk into the appropriate drive, and a message 
indicating the number of records transferred, 
f. Headquarters Menu 

Headquarters menu (Figure 3.17) is intended for a 
Headquarters command to facilitate transfer of DIRS data from 
subordinate dental commands, and the obligatory submission of 
DIRS reports. To that end, file import/export facilities are 
provided as menu options for operation from within the DIRS 
application. 


NAVAL DENTAL CLINIC, LONG BEACH, CA. 13:53:44 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.6 


HEADQUARTER'S MENU 

IMPORT FILES 
EXPORT FILES 
DO REPORTS 

START NEW YEAR (HQ ONLY) 
RETURN TO MAIN MENU 


USE UP AND DOWN CURSOR KEYS ti TO HIGHLIGHT ITEM AND 
PRESS<RETURN> 


Figure 3.17 Headquarter's Menu 


"IMPORT FILES" option is provided to receive files 
transmitted from subordinate commands. Similarly, the "EXPORT 
FILES" option is provided to allow a Headquarters command to 
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send a pre-selected month of data for all of its subordinate 
commands. Selection of the "DO REPORTS” option will result in 
the display of the screen presented in Figure 3.18 with 
provisions for selection of either the DIRS OCR format monthly 
report or a "PROVIDERS STATS” internal report option. 


NAVAL DENTAL CLINIC, LONG BEACH, CA. 13:53:44 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.6.2 


HEADQUARTER'S REPORTS 

MONTHLY DIRS REPORT 
PROVIDER STATS. 

RETURN TO MAIN MENU 


USE UP AND DOWN CURSOR KEYS ti TO HIGHLIGHT ITEM AND 
PRESS<RETURN> 

Figure 3.18 Headquarters Report Menu 

The "MONTHLY DIRS REPORT" selection option is 
supported by the menu screen presented in Figure 3.19. This 
selection will enable Headquarters to print the standard 
monthly NAVMED 6600/8 OCR form required for submission of DIRS 
data to COMNAVMEDCOM using an OCR font capable printer. 

The Provider Stats option at Headquarters level is 
a compilation of all subordinate DTF's Provider Stats reports, 
an example of the Provider Stats Report is provided in 
Appendix H. 
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NAVAL DENTAL CLINIC, LONG BEACH, CA. 11:50:26 11/10/89 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.5.1 


SELECT UIC: 00000 
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0) 

RETURN TO MAIN MENU 




SELECT (0-5)? 1 


IS DATA CORRECT (Y/N)? 


Figure 3.19 HQ OCR DIRS SCREEN 

The "START NEW YEAR (HQ ONLY)” option provided on 
the Headquarters menu is identical in function to that 
provided by the "START NEW YEAR” option for subordinate DTFs 
except that it only reinitializes the Stats database. As 
previously discussed, this option is used to initialize 
records to zero, providing recordkeeping functions for a new 
reporting year; either calendar, fiscal or other arbitrary 
selection. 
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IV. SYSTEM IMPLEMENTATION 


A. INTRODUCTION 

The final step in systems analysis is system 
implementation. At this step, the chief objective is in 
building the system physical design which provides precise 
functionality users desire, and most closely mirrors logical 
design specifications. It is in this step that the components 
of database design, relations, rows and attributes, are 
translated into DBMS-specific tables, records and fields. 

The DBMS selected for use in this task is dBASE III PLUS, 
a product of Ashton-Tate. The specifics of both dBASE III 
PLUS, and QUICKSILVER, the compiler program used, will be 
addressed following a discussion of methods used to generate 
database tables and screens. 

1. Tables 

During user requirements phase, application data 
requirements were identified and were presented as objects. 
These objects were then translated into relations in the 
logical design phase. In the implementation phase, these 
relations are translated into DBMS-specific (in this 
application, dBASE III PLUS) tables. "The order of fields 
within a record is the same for every record in the file, and 
is called the file structure." [Ref. 4] This file structure 
is designed to support specifics of individual DBMSs by 
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establishing the order, length, number of fields and data type 
in each record. 

2. Screen Design 

During user requirements phase, the second task was to 
fully specify system functional requirements. The established 
methodology to most easily describe the requirements is 
through the use of dataflow diagrams (DFD). A dataflow 
diagram is "a chart used by systems analysts to illustrate 
business functions and their data interfaces. Sometimes 
called a bubble chart." [Ref. 3] During logical design phase 
DFDs were converted into menus. Use of these menus serves as 
a control mechanism to prevent update anomalies during file 
maintenance operations (insertions, deletions, and 
modifications). In the implementation phase menus are 
translated, providing a mechanism to manipulate data through 
screens or views, which are materializations of objects. An 
object is a specific instance or representation of one 
particular entity such as a provider or a treatment. It is 
important to note that "entities are perceptions and may or 
may not be physical." [Ref. 3] This distinction is important 
because a screen or view may represent rows and columns from 
a single table, several tables, or may form a separate and 
distinct depiction (view) not associated with a physical table 
or tables. This virtual table is defined by the user's view. 
An example of each screen used to develop the application is 
located in Appendix K. 
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B. dBASE III PLUS 


The dBASE series is by far the dominant data management 
software for the IBM PC.... Beginning with the introduction 
of dBASE II in January 1981 (before the announcement of the 
PC), and continuing with dBASE III in 1984, dBASE III PLUS 
in 1986, and dBASE IV in 1988, Ashton-Tate has remained the 
unquestioned market leader. [Ref. 5] 

Though potentially more powerful Standard Query Language 
(SQL)-based relational database management systems are 
commercially available, dBASE III Plus was selected for use 
in developing this application. There are numerous reasons 
for selection of this particular product, among them; the 
established reputation of the product as one of the industry 
standard programming languages for developing applications 
software on microcomputers, availability of after-market 
compiler and debugger software for the DBMS, user and 
programmer familiarity with the product, and program 
availability within many Navy commands. An important user- 
defined goal for application development effort is related to 
hardware and system requirements imposed on the user. As 
described in Chapter I, developer goals to satisfy user 
requirements included an imbedded DBMS in a compiled DIRS 
application capable of use on existing hardware (in the case 
of the U.S. Navy dental community, an IBM-compatible system 
with a minimum 20 megabyte hard disk) . A product of this 
nature would not require additional off-the-shelf database 
software purchases. 

dBASE III PLUS includes a wide range of application 
development tools and supports three basic user interaction 
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modes: assist, interactive, and programming language. [Ref. 

6 ] 

The bulk of application development work on this project 
was performed using dBASE III PLUS as a programming language. 
In this capacity, maximum flexibility for custom development 
is facilitated. The software development cycle followed by 
the dBASE programmer as defined in [Ref. 6;p. 35], is: 

Problem definition. 

Database design. 

Modular program design. 

Coding. 

Testing, debugging, and enhancing. 

The similarity to the overall application development 
cycle is apparent, with emphasis on detailed requirements 
analysis prior to coding through structured programming and 
top-down design. Critical to goal attainment of reduced 
software purchases, use on existing hardware, and streamlined 
user training, is availability of after-market DBMS-specific 
program compilers. Not all DBMS products possess the facility 
within the program to compile developed code for conversion 
into DOS-executable .exe files capable of operation 
independent of the DBMS software. A significant market 
introduction delay for compiler programs exists for even the 
most commercially successful DBMS. Programmer familiarity and 
availability of Quicksilver a WordTech Systems, Inc. product, 
resulted in its selection as the compiler used in developing 
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this application, though other packages such as Clipper, a 
product of Nantucket, Inc., are available. 

The Quicksilver compiler supports most dBASE III PLUS 

functions, and provides additional user defined functions such 

as specification of programs and files in separate drives or 

directories, networking commands, file-sharing capabilities, 

facilities for developing windows for pop-up menus and help 

screens, and support for environmental variables. An 

additional benefit derived from compiled applications is 

increased program execution speed for processes not "heavily 

disk bound" or requiring access to peripherals such as screens 

or printers. Each time a disk or external device must be 

accessed, program execution is slowed. 

Compiling a custom system does not guarantee that the entire 
system is suddenly going to run at the speed of light. Keep 
in mind that a compiler basically just preinterprets your 
command files and stores these already interpreted commands 
in a separate file. It does not make the hardware operate 
any faster. [Ref. 6:p. 817] 

While dramatic speed improvements are indeed possible, they 
are subject to the limitations described above. A further 
advantage of Quicksilver is the optional linker, allowing 
users to specify "the type of machine the compiled program 
will be run on" [Ref. 5], such as IBM PCs, 100%-compatibles, 
and MS-DOS machines. 
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C. SOFTWARE DOCUMENTATION 


1. User Manual 

Provisions for a detailed user manual are made in 
Appendix K. Written with a user perspective, including 
limited system development background, the user manual is 
intended to support users with varying computer application 
experience by providing detailed menu and screen format 
examples. A menu hierarchy is provided and followed to 
describe the user options available. Each figure depicted in 
the manual is accompanied by related text describing the menu 
options, selection consequence, escape procedures and any 
special-purpose or function key operation. No previous user 
familiarity with either dBASE III PLUS or Quicksilver is 
necessary or assumed. 

2. Program Code 

As previously described, all required program coding 
was written using the programming language function of dBASE 
III PLUG. The length of the program code (141 pages) 
precludes its incorporation as an appendix. However, in order 
to enable easier end-user maintenance, source code will be 
submitted in hard-copy under separate correspondence, and on 
floppy disk with the complete DIRS program for delivery to end 
users. 

D. REPORTS 

System users have a number of reporting options for both 
internal management and DOD-mandated submissions. Among the 
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available options for branch clinics are: daily, monthly and 
annual reports, provider statistics (stats), and major 
treatment reports. At Headquarter's level, in addition to the 
receipt of reports from respective subordinate clinics, 
cumulative provider stats and the monthly DIRS report are 
available as reporting options. An example of each report is 
presented in Appendix H. 
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V. CONCLUSIONS AND RECOMMENDATIONS 


A. SUMMARY AND CONCLUSIONS 

The frequency and volume of treatment data collected and 
stored by various Dental Treatment Facilities severely taxes 
manual data handling and report generating capabilities of the 
limited administrative staff at each facility. Critical to 
the success of the application is increasing the speed and 
accuracy of data input, thereby enhancing effectiveness and 
productivity of the unit, without imposing additional hardware 
requirements or burdening users with complex, lengthy software 
training procedures. 

The DIRS system developed in the course of this thesis not 
only facilitates data entry procedures and monthly preparation 
of DOD-directed reports, but also supports data import/export 
functions from subordinate DTFs to a Headquarters command. 
Personnel management and reporting procedures are provided to 
support internal management at either subordinate DTF or 
Headquarters level. 

As discussed in the previous chapter, dBASE III PLUS was 
selected to develop the DIRS application. By compiling the 
resulting source code through the use of Quicksilver, users 
need not be familiar with dBASE to understand and use the DIRS 
program. While "user friendliness" is a desirable attribute 
of any system, it is often an ill-defined and elusive goal. 
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In this application, emphasis on extensive menus and selection 
keys function as control mechanisms help guide the user 
through the system. Crucial to user acceptance, extensive 
documentation and supporting diagrams are provided in the 
User's Manual found in Appendix K. Additional "hands-on" 
experience should provide the remaining system training 
requirements. 

B. RECOMMENDATIONS AND FUTURE WORK 

The process of developing this application provided 
numerous "case-study" examples of the importance of correctly 
defining user requirements prior to initializing development 
work. The process was facilitated by knowledgeable users with 
generally well-defined and reasonably consistent structured 
data flows. Geographical distance between users and 
developers posed some difficulties, so phone conversations, 
mailings and personal visits to NAVDENCLINIC, Long Beach, Ca. , 
and Director of Dental Services, San Diego, Ca., were crucial 
to an effective requirements definition process and user 
familiarization training. Developing and mailing an early 
prototype of DIRS to both user sites provided an exceptionally 
valuable mechanism to not only further clarify requirements, 
but also identify several previously overlooked program 
anomalies. Evolving user requirements and subsequent 
identification of additional features and modules for addition 
to future versions of the DIRS application developed in the 
scope of this thesis, provide opportunities for program 
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expansion either internally or within the scope of 
proposed DENMIS system. 


the 
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YEAR 


MONTHLY 


COMMAND 

MONTHLY 

MV 

Tot Yr. BCat 01 
Tot Yr. BCat 02 
Tot Yr. BCat 06 
Tot Yr. BCat 08 
Tot Yr. BCat 08 
Tot Yr. BCat 10 
Tot Yr. BCat 11 
Tot Yr. BCat 12 
Tot Yr. BCat 13 


DAILY 


PROVIDER 


ITREATMENT 

Date 

Tot Oly. BCat 01 
Tot Dly. BCat 02 
Tot Dly. BCat 05 
Tot Dly. BCat 08 
Tot Oly. BCat 00 
Tot Dly. BCat 10 
Tot Dly. BCat 11 
Tot Dly. BCat 12 
Tot Dly. BCat 13 


COMMAND 

DAILY 

MV 

Month 

Tot Mon. BCat 01 
Tot Mon. BCat 02 
Tot Mon. BCat 06 
Tot Mon. BCat 08 
Tot Mon. BCat 09 
Tot Mon. BCat 10 
Tot Mon. BCat 11 
Tot Mon. BCat 12 
Tot Mon. BCat 13 


BENEFICIARY CODES; 


01 * Active Duty, Li.8. Navy 

02 - Active Duty, U.8. Marine Corps 

05 - Active Duty, Other Services 

08 - Recruit, LI.8. Navy or Marine Corps 

09 - Dependents of Active Duty 

U.S. Uniformed Services Personnel 

10 - Dependents of Retired or Deceased 

U.S. Uniformed Services Personnel 

11 - Retired Uniformed Servioea Peraonne 

12 - Other Personnel not listed in Codes 

01 through 11 and 13 

13 - Dependent Children, 

<17 & under and unmarried) 
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APPENDIX B 


OBJECT DEFINITIONS 


STATS (HQ) OBJECT 

Descriptive Name _ Domain Name 

Unit Identification Code Clinic 

COMMAND: COMMAND object; MV 


COMMAND OBJECT 


Descriptive Name 


Domain Name 


Unit Identification Code 
Command Name 
MEPERS Work Center Code 
PROVIDER; PROVIDER object; 

YEAR: YEAR object; 


Clinic 

Command 

UCA_code 

MV 

MV 


PROVIDER OBJECT 
Descriptive Name _ 


Domain Name 


Provider Code 
First Name 
Last Name 
Military Rank 
Duty Status 

DAILY; DAILY object; 


Code 

Fname 

Lname 

Rank 

Reserve 

MV 


TREATMENT 
(DIRS CODE) OBJECT 

Descriptive Name _ Domain Name 


DIRS Code Dirs 

Description Descript 

Comp Value (time) Weight 

DAIT.v? DAILY object; MV 
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YEAR OBJECT 


Descriptive Name _ Domain Name 

Year Total to date for 

Beneficiary Category 01 Tot Yr. BCat 01 

Year Total to date for 

Beneficiary Category 02 Tot Yr. BCat 02 

Year Total to date for 

Beneficiary Category 05 Tot Yr. BCat 05 

Year Total to date for 

Beneficiary Category 08 Tot Yr. BCat 08 

Year Total to date for 

Beneficiary Category 09 Tot Yr. BCat 09 

Year Total to date for 

Beneficiary Category 10 Tot Yr. BCat 10 

Year Total to date for 

Beneficiary Category 11 Tot Yr. BCat 11 

Year Total to date for 

Beneficiary Category 12 Tot Yr. BCat 12 

COMMAND: COMMAND object 

MONTHLY: MONTHLY object; MV 


MONTHLY OBJECT 

Descriptive Name _ Domain Name 

Month Total to date for 

Beneficiary Category 01 Tot Mon. BCat 01 

Month Total to date for 

Beneficiary Category 02 Tot Mon. BCat 02 

Month Total to date for 

Beneficiary Category 05 Tot Mon. BCat 05 

Month Total to date for 

Beneficiary Category 08 Tot Mon. BCat 08 

Month Total to date for 

Beneficiary Category 09 Tot Mon. BCat 09 

Month Total to date for 

Beneficiary Category 10 Tot Mon. BCat 10 

Month Total to date for 

Beneficiary Category 11 Tot Mon. BCat ll 

Month Total to date for 

Beneficiary Category 12 Tot Mon. BCat 12 

COMMAND: COMMAND object; 

DAILY: DAILY object; MV 
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DAILY OBJECT 


Descrip 't'-^ ve Name--- 

Daily Total for 
Beneficiary Category 01 
Daily Total for 
Beneficiary Category 02 
Daily Total for 
Beneficiary Category 05 
Daily Total for 
Beneficiary Category 08 
Daily Total for 
Beneficiary Category 09 
Daily Total for 
Beneficiary Category 10 
Daily Total for 
Beneficiary Category 11 
Daily Total for 
Beneficiary Category 12 
PROVIDER: PROVIDER 

TREATMENT: TREATMENT 


Domain Name 

Tot Dly. BCat 01 
Tot Dly. BCat 02 
Tot Dly. BCat 05 
Tot Dly. BCat 08 
Tot Dly. BCat 09 
Tot Dly. BCat 10 
Tot Dly. BCat 11 
Tot Dly. BCat 12 

obj ect 
object 
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APPENDIX C 


CLINIC: 

COMMAND: 

UCA_Code: 

PROVCODE: 

FNAME: 

LNAME: 

RANK: 

RESERVE: 


DOMAIN DEFINITIONS 


Number(5) 

This number represents the unique 5-digit Unit 
Identification Code (UIC) assigned to every 
military command. Each DTE has an individually 
assigned UIC, which is required on all 
forms submitted. 

Character(40) 

The full DTE name as listed in the NAVMEDCOMINST 
6600.IB, Chapter III. 

Character(4) 

The 4-digit MEPERS (UCA) code for each work 
center. The first three digits distinguish 
between dental clinical or laboratory procedures, 
while the fourth digit represents the location 
(work center) where the procedure was performed. 

Character(3) 

The provider code is a three-digit code assigned 
to uniquely represent a dental provider at a 
given DTE. 

Character(20) 

Dental provider's first name. 

Character(20) 

Dental provider's last name. 

Character(4) 

Dental provider's military or civilian rank, 
i.e.; CAPT. 

Character(1) 

Dental provider's status. Three values can be 
inserted here. "C" for civilian contractor, "R" 
for reservist performing two weeks active duty, 
or "0" for other. "O" shall be the default 
value. 
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DIRS: 


DESCRIPT: 

WEIGHT: 


TOTl : 


TOT2 : 


TOT 5: 


TOTS: 


TOT9 : 


TOTIO: 


TOTH: 


Character(4), range: 0001 to 9999. 

Actual command treatment code. Although 
specified as a character field, a built-in 
control mechanism allows only numeric values to 
be entered. The DIRS code identifies a specific 
treatment. 

Character(15) 

Short description (name) of a DIRS code. 

Number(4), Picture 999.9 

Each DIRS code as a composite factor (weight) 
associated with it. This weight is used for 
computing total time spent per a requested time 
frame for a particular treatment. 

Number(7), picture 9999.99 

The sum of all category one beneficiary code for 
a specific treatment and specific provider for 
the year multiplied by its associated weight. 

Number(7), picCure 9999.99 

The sum of all category two beneficiary code for 
a specific treatment and specific provider for 
the year multiplied by its associated weight. 

Number(7), picture 9999.99 

The sum of all category five beneficiary code for 
a specific treatment and specific provider for 
the year multiplied by its associated weight. 

Number(7), picture 9999.99 

The sum of all category eight beneficiary code 
for a specific treatment and specific provider 
for the year multiplied by its associated weight. 

Number(7), picture 9999.99 

The sum of all category nine beneficiary code for 
a specific treatment and specific provider for 
the year multiplied by its associated weight. 

Number(7), picture 9999.99 

The sum of all category ten beneficiary code for 
a specific treatment and specific provider for 
the year multiplied by its associated weight. 

Number(7), picture 9999.99 

The sum of all category eleven beneficiary code 
for a specific treatment and specific provider 
for the year multiplied by its associated weight. 
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TOT12; 


TOT13: 


M totl: 


M tot2: 


M tot5: 


M tots: 


M tot9: 


M totlO: 


M totll: 


Number(7), picture 9999.99 

The sum of all category twelve beneficiary code 
for a specific treatment and specific provider 
for the year multiplied by its associated weight. 

Number(7), picture 9999.99 

The sum of all category thirteen beneficiary code 
for a specific treatment and specific provider 
for the year multiplied by its associated weight. 

Number(5), Picture 99999 

Total number of treatment provided for a specific 
treatment by a specific provider for beneficiary 
code 1. A cumulative count of D_totl domain for 
the user's open month selection. 

Number(5), Picture 99999 

Total number of treatment provided for a specific 
treatment by a specific provider for beneficiary 
code 2. A cumulative count of D_tot2 domain for 
the user's open month selection. 

Number(5), Picture 99999 

Total number of treatment provided for a specific 
treatment by a specific provider for beneficiary 
code 5. A cumulative count of D_tot5 domain for 
the user's open month selection. 

Number(5), Picture 99999 

Total number of treatment provided for a specific 
treatment by a specific provider for beneficiary 
code 8. A cumulative count of D_tot8 domain for 
the user's open month selection. 

Number(5), Picture 99999 

Total number of treatment provided for a specific 
treatment by a specific provider for beneficiary 
code 9. A cumulative count of D_tot9 domain for 
the user's open month selection. 

Number(5), Picture 99999 

Total number of treatment provided for a specific 
treatment by a specific provider for beneficiary 
code 10. A cumulative count of D_totl0 domain 
for the user's open month selection. 

Number(5), Picture 99999 

Total number of treatment provided for a specific 
treatment by a specific provider for beneficiary 
code 11. A cumulative count of D_totll domain 
for the user's open month selection. 
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M totl2: 


M totl3: 


D TOTl; 


D TOT2: 


D TOTS: 


D TOTS: 


D TOT9: 


D TOTIO: 


D TOTll: 


D TOT12: 


Number(5), Picture 99999 

Total number of treatment provided for a specific 
treatment by a specific provider for beneficiary 
code 12. A cumulative count of D_totl2 domain 
for the user's open month selection. 

Number(5), Picture 99999 

Total number of treatment provided for a specific 
treatment by a specific provider for beneficiary 
code 13. A cumulative count of D_totl3 domain 
for the user's open month selection. 

Number(5), Picture 99999 

Total number .of treatment provided for a specific 
treatment by a specific provider for beneficiary 
coda 1. 

Number(5), Picture 99999 

Total number of treatment provided for a specific 
treatment by a specific provider for beneficiary 
code 2. 

Number(5), Picture 99999 

Total number of treatment provided for a specific 
treatment by a specific provider for beneficiary 
code 5. 

Number(5), Picture 99999 

Total number of treatment provided for a specific 
treatment by a specific provider for beneficiary 
code 8. 

Number(5), Picture 99999 

Total number of treatment provided for a specific 
treatment by a specific provider for beneficiary 
code 9. 

Number(5), Picture 99999 

Total number of treatment provided for a specific 
treatment by a specific provider for beneficiary 
code 10. 

Number(5), Picture 99999 

Total number of treatment provided for a specific 
treatment by a specific provider for beneficiary 
code 11. 

Number(5), Picture 99999 

Total number of treatment provided for a specific 
treatment by a specific, provider for beneficiary 
code 12. 
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D T0T13: 


Nuniber(5), Picture 99999 

Total number of treatment provided for ^ • 

treatment by a apecific provider for benefi^Ur^ 
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APPENDIX D 


DATA FLOW DIAGRAMS 


DINK UA'm 


























APPENDIX E 


UPDATE. DISPLAY AND CONTROL MECHANISMS 


PROVIDER OBJECT 
Update Mechanisms 


I. Create PROVIDER 

A. Input Description 

Provider code assigned by database administrator 
Provider name (last and first name) 

Rank or rate 

Status code (R = reservist, C = contracted 
personnel, 

O = others that are not R or C) 

B. Output Description 

- New PROVIDER object 

C. Processing Notes 

System shall check to ensure that no two 
providers have the same provider code 

D. Volume 

Approximately six to ten providers per dental 
clinic 

Volume is dependent on the size of command 

E. Frequency 

Created when a new provider checks onboard 


II. Modify PROVIDER 

A. Input Description 

Correction to provider listing 

- PROVIDER object 

B. Output Description 

- Modified PROVIDER object 

Confirmation message while updating on screen 

C. Processing Notes 

System shall not allow user to modify key field 
(provider code) 
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D. Volume 

One record correction per quarter 

E. Frequency 

One record correction per quarter 


III. Delete PROVIDER 

A. Input Description 

Transferred personnel report 
- PROVIDER object 

B. Output Description 

updated PROVIDER object 

Confirmation message to delete record on screen 

C. Processing Notes 

Record is displayed for confirmation. User must 
respond affirmatively to the prompt to delete 
record 


D. 

Volume 

Varies 

with 

the 

number 

of 

transfers 

E. 

Frequency 

Varies 

with 

the 

number 

of 

transfers 


PROVIDER OBJECT 
Display Mechanisms 


I. PROVIDER listing 

A. Output Description 

Form showing provider code, first and last name, 
rank and status code (R, C, O) 

B. Source data 

PROVIDER object 

C. Processing Notes 

Produce weekly by database administrator 

D. Volume 

One report per week 

E. Frequency 

One report per week 
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PROVIDER OBJECT 
Control Mechanisms 


I. Pop-up windows, system validation routines, along with 
user prompts 


TREATMENT OBJECT 
Update Mechanisms 


I. Create TREATMENT 

A. Input Description 

DIRS treatment codes, description, and Critical 
Time Value (CTV) are specified in NAVMEDCOMINST 
6600.IB 

New code created by Bureau of Medicine (BUDMED) 

B. Output Description 

New TREATMENT object 

C. Processing Notes 

System shall ensure that each treatment code is 
unique 

- This table will be created for the user 

D. Volume 

Approximately three hundred codes 

E. Frequency 

Once at system development 


II. Modify TREATMENT 

A. Input Description 

Correction to initial entries made during system 
implementation 

- Changes made to NAVMEDCOMINST 6600.IB 

B. Output Description 

Modified TREATMENT object 

Confirmation message while updating on screen 

C. Processing Notes 

System shall not allow user to modify key field 
(treatment code) 

D. Volume 

Extremely low 
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E. Frequency 

- Approximately once every two years some of the 
treatment codes may change or its CTV will 
change. These changes are determined at an 
echelon 2 command level not at an echelon 3 or 4 
command where this system is designed for use 


III. Delete TREATMENT 

A. Input Description 

Invalid treatment code entered during creation 
Outdated treatment codes that have been deleted 
in NAVMEDCOMINST 6600.IB 

B. Output Description 

Updated TREATMENT object 

Confirmation message while updating on screen 

C. Processing Notes 

System shall allow user verification to modify 
key 

Confirmation message to delete record on screen 

D. Volume 

Extremely low 

E. Frequency 

Approximately once every two year some of the 
treatment codes may change or its CTV will 
change. These changes are determined at an 
echelon 2 command level not at an echelon 3 or 4 
command where this system is designed for use 


TREATMENT OBJECT 
Display Mechanisms 


I- TREATMENT listing 

A. Output Description 

- Form showing treatment (DIRS) code, description, 
CTV (weight) 

B. Source data 

- TREATMENT Object 

C. Processing Notes 

This object is used for treatment code 
validation while updating the DAILY, MONTHLY, 
and YEARLY object 
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D. Volume 

One report to verify any updates 

E. Frequency 

One per year 


TREATMENT OBJECT 
Control Mechanisms 


I. Pop-up windows, system validation routines, along with 
user prompts 


DAILY OBJECT 
Update Mechanisms 


I. Create Daily 

A. Input Description 

Month selection (from menu selection options) 
Provider selection (from provider object) 
Treatment code selection (from treatment object) 
- Manual data entry of totals for each beneficiary 
(category) code treated (from daily providers' 
work sheet) 

B. Output Description 

New DAILY object in database 
Updated MONTHLY object in database 
Updated YEARLY object in database 
Confirmation message of updates on screen 
Online monthly and yearly totals for selected 
treatment and individual provider on screen 
On demand Hardcopy availability of input data 
for the data entry session 

C. Processing Notes 

The DAILY object is initialized with each 
session, therefore the Daily report will only 
reflect information keyed in during the current 
session 

D. Volume 

Average number of different treatments per 
provider is 26 treatments per day. Each clinic 
averages six providers per work-day (Monday 
through Friday) 
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E. Frequency 

Once per day or one per session (when data is 
entered). Users have specified that data is 
entered at minimum once per week 
Minimum one per week 


II. Modify DAILY data 

A. Input Description 

Changes or errors noted on daily providers' work 
sheet) 

Data entry errors not corrected at initial entry 
need to be corrected 

Procedure same as with create DAILY except that 
negative or positive values are entered to 
correctly adjust the monthly and yearly totals 
for a requested provider, treatment and month 

B. Output Description 

Modified DAILY object in database 
Modified MONTHLY object in database 
Updated YEARLY object in database 
Confirmation message of updates on screen 
Online monthly and yearly totals for selected 
treatment and individual provider on screen 
On demand Hardcopy availability of input data 
for the modification data entry session 

C. Processing Notes 

The DAILY object is initialized with each new 
data entry session, therefore the Daily report 
will only reflect information keyed in during 
this session 

D. Volume 

One day per month, ten treatments 

E. Frequency 

As needed 

Modification are generally only needed due to 
erroneous data entry. Since control mechanisms 
are built into the system, prompting data entry 
personnel to validate entry before entry is 
accepted into the database, these type of errors 
are infrequent 
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III. Delete DAILY data 


A. Input Description 

Procedure same as with create DAILY except that 
negative values are entered to correctly 
adjust the monthly and yearly totals for a 
requested provider, treatment and month 
The DAILY object is deleted automatically when 
the system is executed for the first time 
during the day. A new DAILY object reflecting 
the new transaction is then generated 

B. Output Description 

Modified DAILY object in database reflecting 
deleted transactions 
Updated MONTHLY object in database 
Updated YEARLY object in database 
Confirmation message of updates on screen 
Online monthly and yearly totals for selected 
treatment and individual provider on screen 
On demand Hardcopy availability of input data 
for the modification data entry session 

C. Processing Notes 

The DAILY object is initialized with each new 
data entry session. Therefore the Daily report 
will only reflect information keyed in during 
this session 

D. Volume 

One to two records per entry session 

E. Frequency 

As required 


DAILY OBJECT 
Display Mechanisms 


I. Daily Report 

A. Output Description 

- Form showing by beneficiary codes, and all 
treatments, performed by each provider. The 
report shall total the number of treatments for 
a single treatment code with its associated 
composite time value total (CTV)(weighted time) 
total number treatment performed times its CTV) 
for all active Navy and retired personnel. The 
form shall also give a one-line summary of the 
work performed for each provider. A new page is 
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used for every provider. The command daily 
summary shall also be printed on a separate 
sheet in the same prestated format. See 
Appendix K for an example of the daily summary 

B. Source data 

DAILY object 

C. Processing Notes 

Daily object contains PROVIDER, TREATMENT object 
data 

- Use at local command and distributed to each 
provider for accuracy validation 

D. Volume 

One for entry clerk 

One copy for each provider 

One copy to the administration officer 

E. Frequency 

One daily or one per data entry session 


DAILY OBJECT 
Control Mechanisms 


I. Pull-dovn menus, pop-up windows, system validation 
routines, along with user prompts 


MONTHLY OBJECT 
Update Mechanisms 


I. Create Monthly 

A. Input Description 

DAILY object automatically updates the MONTHLY 
object for the selected month 

B. Output Description 

Updated MONTHLY object in database 
Updated YEARLY object in database 
Online monthly and yearly totals for selected 
treatment and individual provider on screen 
On demand Hardcopy availability of work 
performed by provider for a selected month 

C. Processing Notes 

The DAILY object is initialized with each 
new session. Therefore the Daily report will 
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only reflect information keyed in during the 
data entry sitting 

D. Volume 

Average number of different treatments per 
provider is 26 treatments per day times the 
number of work days per month. Each clinic 
averages six providers per work-day (Monday 
through Friday) 

E. Frequency 

Since DAILY object automatically updates the 
MONTHLY object the frequency is the same as for 
the DAILY object update 
Minimum one per week 


II. Modify MONTHLY data 

A. Input Description 

Changes or errors noted on daily providers' work 
sheet 

Data entry errors not corrected at initial entry 
need to be corrected 

Procedure same as with create DAILY except that 
negative oi positive values are entered to 
correctly adjust the monthly and yearly totals 
for a requested provider, treatment and month 

B. Output Description 

Modified DAILY object in database 
Modified MONTHLY object in database 
Updated YEAR object in database 
Confirmation message of updates on screen 
Online monthly and yearly totals for selected 
treatment and individual provider on screen 
On demand Hardcopy availability of input data 
for the modification data entry session 

C. Processing Notes 

The MONTHLY object is modified via the update 
daily mechanism which updates the DAILY object 
as well as the MONTHLY 

D. Volume 

Number of treatments is dependent on the number 
of incorrect daily entries made during a given 
month. Errors are generally corrected via the 
validated daily provider's report which is 
returned to the DIRS data entry clerk 
Low 
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E. Frequency 

As required 

Modification are generally only needed due to 
erroneous data entry. Since control mechanism 
are built in the system which prompt data entry 
personnel to validate entry before entry is 
accepted into the database, these type of errors 
are infrequent 


III. Delete MONTHLY data 

A. Input Description 

- Procedure same as with update DAILY except that 
negative values are entered to correctly 
adjust the monthly and yearly totals for a 
requested provider, treatment and month 
The MONTHLY object is deleted through the 
utilities option by selecting the start new year 
option 

B. Output Description 

New database structure created for MONTHLY 
object when a new year is started 
Updated MONTHLY object in database 
Updated YEAR object in database 
Confirmation message of updates on screen 
Online monthly and yearly totals for selected 
treatment and individual provider on screen 
On demand Hardcopy availability of input data 
for the modification data entry session 

C. Processing Notes 

MONTHLY object is automatically updated via the 
update daily module 

D. Volume 

Low 

E. Frequency 

MONTHLY object is deleted once per year 
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MONTHLY OBJECT 
Display Mechanisms 


I. Monthly Report 

A. Output Description 

Same as with Daily object report except that 
information represents monthly figures versus 
daily totals 

Providers' statistical report used by management 
displays provider code, total number of 
treatments, total CTV, and cumulative command 
totals for the selected month. Headquarters may 
also produce similar report provided information 
has been imported from subordinate commands 
Major treatment report allowing user to narrow 
its scope of information by the selection of up 
to ten critical treatment codes. List providers 
along with treatment codes, total number of 
treatments and total CTV 

B. Source data 

Selected MONTHLY object 

- May be selected any time during the year for a 
requested month 

C. Processing Notes 

- MONTHLY object contains COMMAND and DAILY object 
data 

Use at local command and distributed to each 
provider as a feeder sheet on individual 
productivity 

Headquarter maintains an aggregated MONTHLY 
object of all its subordinate command to produce 
an OCR monthly report for submission to 
NAVBUMED, Washington D.C. 

The major treatment report is used by management 
for internal management of provider 
productivity 

A monthly report similar in format to the 
monthly OCR DIRS report produced by HQ. Report 
is not OCR font 

A providers statistics report is produced 
displaying information by provider versus by 
treatment as in the case of monthly reports 

D. Volume 

Minimum three per month 

Any time during a month for an up-to-date report 
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E. Frequency 
Monthly 


MONTHLY OBJECT 
Control Mechanisms 


I. Pull~down menus, pop-up windows, system validation 
routines, along with user prompts provide suitable 
control mechanisms 


YEAR OBJECT 
Update Mechanisms 


I. Create YEAR 

A. Input Description 

DAILY object automatically updates the YEAR 6 
object 

B. Output Description 

Updated MONTHLY object in database 
Updated YEARLY object in database 
Online yearly totals for selected 
treatment and individual provider on screen 

C. Processing Notes 

The YEAR object in created at the start of a new 
year. The DAILY object is the feeder for the 
YEAR OBJECT 

D. Volume 

Average number of different treatments per 
provider is 26 treatments per day times the 
number of work days per year. Each clinic 
averages six providers per work-day (Monday 
through Friday) 

E. Frequency 

As often as the DAILY object is updated 


II, Modify YEAR data 

A. Input Description 

Same as with DAILY and MONTHLY object 
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B. Output Description 

Modified YEAR object in database 
Confirmation message of updates on screen 
Online yearly totals for selected 
treatment and individual provider on screen 

C. Processing Notes 

The YEAR object is modified via the update daily 
mechanism which updates the DAILY object as well 
as the MONTHLY and YEARLY OBJECT database 
automatically 

D. Volume 

- Very low since data has generally been corrected 
by the DAILY and MONTHLY object update 
mechanisms 

Same as per DAILY object 

E. Frequency 

Same as per DAILY object 


III. Delete YEAR data 

A. Input Description 

Procedure same as with update DAILY except that 
negative values are entered to correctly 
adjust the yearly totals for a requested 
provider, treatment and month 

The YEAR object is deleted through the utilities 
option by selecting the start new year option 

B. Output Description 

New database structure created for the YEAR 
object when a new year is started 
Updated YEAR object in database 
- Confirmation message of updates on screen 
Online yearly totals for selected 
treatment and individual provider on screen 

C. Processing Notes 

YEAR object is automatically updated via the 
update DAILY object mechanism 

D. Volume 

Very low 

E. Frequency 

YEAR object is deleted once per year 
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YEAR OBJECT 
Display Mechanisms 


I. Annual Report 

A. Output Description 

Same as with Monthly report except that 
information represents the total number of 
treatment to date for the given year 

P. Source data 

Selected YEAR object 

C. Processing Notes 

YEAR object contains COMMAND and MONTHLY object 
data 

Use at local command and distributed to each 
provider as a feeder sheet on individual 
productivity 

Use by management for planning and budgeting 
function 

Use by management as a verification tools 
against the aggregated monthly reports 
A providers statistics report is produced 
displaying information by provider versus by 
treatment as in the case of a monthly report 

D. Volume 

One per month 
One per year 

Any time during the year 

E. Frequency 

Monthly 

Yearly 


YEAR OBJECT 
Control Mechanisms 


I. Pull-down menus, pop-up windows, system validation 
routines, along with user prompts provide suitable 
control mechanisms 
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COMMAND OBJECT 
Update Mechanisms 


NOTE: This object is different from typical objects as it 

is used solely as a control mechanism to provide users a 
more intuitive, less repetitious system. 

I. Create COMMAND object 

A. Input Description 

Unit Identification Code (UIC) 

Command name 

MEPERS codes for laboratory and clinical 
procedures 

B. Output Description 

New COMMAND object 

Confirmation message of updates on screen 

C. Processing Notes 

This information generally does not change. 
DIRS is designed to support one to nine dental 
clinics 

D. Volume 

One to nine clinics 

E. Frequency 

Once at initial installation 


II. Delete or Modify COMMAND Object 

A. Input Description 

Same as with create COMMAND object 
At DOS prompt file "comm.mem" is deleted 

B. Output Description 

New COMMAND object 

C. Processing Notes 

This information generally does not change 
DIRS is designed to support one to nine dental 
clinics 

D. Volume 

Not applicable 

E. Frequency 

Not applicable 
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COMMAND OBJECT 
Display Mechanisms 


I. Pop-up windows 

A. Output Description 

Help screens displaying and prompting user for 
command or MEPERS selection 

B. Source data 

COMMAND object (alias comm.mem) 

C. Processing Notes 

Mainly used at headquarter (HQ) level where user 
must differentiate between commands 

D. Volume 

Anytime HQ wishes to print report on a 
particular clinic 

E. Frequency 

Varies from command to command 


COMMAND OBJECT 
Control Mechanisms 


I. Pull-down menus, pop-up windows, system validation 
routines, along with user prompts 


II. Automatic UIC entry 

A. Output Description 

Automatically enters command UIC to file that 
will be exported to HQ 

B. Source Data 

COMMAND object 

C. Processing Notes 

User never has to key-in command information for 
updating DAILY, MONTHLY, or YEARLY object thus 
avoiding possible data validity and data entry 
errors 

D. Volume 

Same as with DAILY object update mechanisms 
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E. Frequency 
Daily 


STATS OBJECT 
Update Mechanisms 


I. Create STATS 

A. Input Description 

An aggregate of all data segregated by month for 

an entire year on all subordinate commands 

This object is only maintained at HQ 

Created by importing subordinate command MONTHLY 

object 

B. Output Description 

Updated STATS object at HQ 

C. Processing Notes 

This object is the major feeder for all reports 
that are generated by HQ 

D. Volume 

MONTHLY object for each subordinate clinic 
Approximately 156 records per clinic 

E. Frequency 

Created once per Year 


II. Modify STATS data 

A. Input Description 

Monthly Import file from subordinate command 

B. Output Description 

Updated STATS object at HQ 

C. Processing Notes 

- Automatically modified with import of 
subordinate command 

D. Volume 

One to two records per month per clinic 

E. Frequency 

Once per month 
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III. Delete STATS data 


A. Input Description 

Monthly Import file from subordinate command 

B. Output Description 

- Updated STATS object at HQ 

C. Processing Notes 

Automatically modified with import of 
subordinate command 

The entire object shall be delete once per year 
via menu selection 

D. Volume 

Not applicable since extra treatments are not 
added. Total number of treatments for an 
individual provider and treatment are sometimes 
modified but not deleted 

E. Frequency 

Not applicable 


STATS OBJECT 
Display Mechanisms 


I. Monthly OCR Report and Providers Stats Report 

A. Output Description 

An OCR form for a selected clinic and month 
which must be printed on an OCR printer 
A providers statistics report is identical to 
MONTHLY display mechanism except that it shall 
display all providers productivity within 
chain-of-command of HQ 

B. Source data 

Selected STATS and COMMAND objects 

C. Processing Notes 

STATS object contains COMMAND object data 
Use by management for planning and budgeting 
function 

D. Volume 

As many OCR reports as subordinate clinics 
Stats report is produced at minimum one per 
month 
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E. Frequency 
- Monthly 
Yearly 


STATS OBJECT 
Control Mechanisms 


I. Pull-down menus, pop-up windows, system validation 
routines, along with user prompts. A database 
administrator will be assigned at HQ to manage overall 
system data integrity 
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APPENDIX F 


RELATION DIAGRAM 
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APPENDIX G 


LOGICAL MENU STRUCTURE 


MENU HIERARCHY 
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APPENDIX II 


SAMPLE REPORTS 


NAVAL DENTAL CLINIC, LONG BEACH, CA. 12:49:38 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.4 


REPORT MENU 

DAILY REPORT 
MONTHLY REPORT 
ANNUAL REPORT 
PROVIDERS STATS. 

MAJOR TREATMENT REPORT 

RETURN TO MAIN MENU 


USE UP AND DOWN CURSOR KEYS TO HIGHLIGHT ITEM AND 
PRESS<RETURN> 


Branch Clinic Report Menu 


Documents on the following pages of this appendix depict 
sample reports produced after selection of menu options 
presented from the DIRS Branch Clinic Report Menu screen 
reproduced above. 
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02/05/90 
PAGE 1 


DENTAL INFORMATION RETRIEVAL SYSTEM 
DAILY INPUT REPORT 


PROVIDER; in 


BENEFICIARY CATEGORY CTV CTV CTV 


01 02 

05 

08 

09 

10 

11 

12 

13 

TOTAL 

TOTAL 

NAVY 

RETIRED 

•• TREATMENT 
5.0 0.0 

CODE; 

2.0 

0001 

3.0 

* * 

22.0 

33.0 

0.0 

0.0 

1.0 

66.0 

132.C 

10.0 

0.0 

•• TREATMENT 
3.0 0.0 

CODE; 

0.0 

5752 

3.0 

* * 

34.0 

0.0 

33.0 

0.0 

9.0 

82.0 

344.4 

12.6 

138.6 

PROVIDER TOTALS 

01 02 05 

BENEFICIARY CATEGORY 

08 09 10 11 

12 

13 

TOTAL 

CTV 

TOTAL 

CTV 

NAVY 

CTV 

RETIRED 

8.0 0.0 

2.0 

6.0 

56.0 

33.0 

33.0 

0.0 

10.0 

148.0 

476.4 

22.6 

138.6 
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02/05/90 
PAGE 2 


DENTAL INFORMATION RETRIEVAL SYSTEM 
DAILY INPUT REPORT 


TOTALS 

01 

FOR TODAY 

02 05 

BENEFICIARY CATEGORY 

08 09 10 11 

12 

13 

CTV 

TOTAL TOTAL 

CTV CTV 

NAVY RETIRED 

8.0 

~5T0 2.0 

STTO 3370 33.0 

0.0 

10.0 

148.0 476.4 

22.6 138.6 
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Page No. 
02/05/90 


1 


DENTAL INFORMATION 
RETRIEVAL SYSTEM 
TREATMENT REPORT 
FOR the month of JUNE 

CTV CTV CTV 

CTOl CT02 CTOS CTOS CT09 CTIO CTll CT12 CT13 TOTAL TOTAL NAVY RET. 


** DIRS 0001 
** Subtotal *• 

36 00000000 36 02.0 72.0 0.0 

** DIRS 0002 

** Subtotal •* 

700000000 7 28.0 28.0 0.0 

•• DIRS 0003 
•* Subtotal *» 

50000 0. 000 5 25.0 25.0 0.0 

•* DIRS 0004 
•• Siibtotal •• 

12 00000000 12 48.0 48.0 0.0 

•* DIRS 0005 
** Subtotal •» 

1 0 0 0 0 0 0 0 0 1 5.0 5.0 0.0 

»• DIRS :006 
** Subtotal *• 

26 00000000 26 26.0 26.0 0.0 

** DIRS 0007 
*• Subtotal •* 

100000000 1 2.0 2.0 0.0 
** DIRS 0010 
** Subtotal ** 

18 00000000 18 90.0 90.0 0.0 

*• DIRS 0011 
** Subtotal *• 

37 00000000 37 74.0 74.0 0.0 
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Page No. 11 
02/05/90 


DENTAL INFORMATION 

retrieval system 

TREATMENT REPORT 
FOR THE MONTH OF JUNE 


CTV CTV 



CTOl CT02 

CTOS 

CT08 

CT09 

CTIO 

CTll 

CT12 

CT13 

TOTAL 

TOTAL 

NAVY 

* « 

DIRS 9918 












* * 

Subtotal •* 
38 

0 

1 

0 

0 

0 

4 

0 

0 

43 

21,5 

19.0 

* * 

DIRS 9923 












* * 

Subtotal ** 
21 

1 

6 

0 

0 

1 

1 

0 

0 

36 

28.8 

21.6 

t * 

DIRS 9972 












* « 

Subtotal •* 
512 

4 

17 

0 

20 

4 

20 

6 

6 

589 

471,2 

409.6 

* « 

DIRS 9973 












It * 

Subtotal •• 
346 

0 

17 

0 

8 

8 

23 

3 

0 

405 

445.5 

380.6 

*** Total *** 
5583 

21 

200 

1 

121 

56 

231 

30 

22 

6265 

5221.8 

4721.3 


104 


CTV 

RET. 


2.0 

0.8 

16.0 

25.3 

153.6 




Page No. 11 
02/24/90 

DENTAL INFORMATION 
RETRIEVAL SYSTEM 
yearly treatment REPORT 



CTOl CT02 

CTOS 

CTOS 

CTOS 

CTIO 

CTl 1 

CT12 

CT13 

TOTAL 

CTV 

TOTAL 

CTV 

NAVY 

CTV 

RET, 

«« 

DIRS 9918 












*« 

Subtotal «* 
195 1 

7 

0 

2 

0 

25 

1 

2 

233 

116.5 

97.5 

12.5 

*« 

DIRS 9923 












*« 

Subtotal ** 
255 4 

21 

0 

0 

1 

3 

0 

0 

284 

227.2 

204.0 

2.4 

• * 

DIRS 9972 












*« 

Subtotal ** 
3769 89 

121 

0 

136 

11 

270 

93 

79 

4568 

3654.4 

3015.2 

216.0 


DIRS 9973 












«« 

Subtotal ♦♦ 
2222 16 

94 

0 

45 

12 

169 

8 

8 

2574 

2831.4 

2444.2 

185.9 

Total *** 
40459 532 

1297 

-> 

793 

124 

2329 

432 

357 

46325 

34610.7 

31066.5' 

1358.0 


105 






NAVAL POSTGRADUATE SCHOOL, MONTEREY, CA. 

Page No: 1 

PROVIDER SUMMARY REPORT 
FOR THE MONTH OF JUN 1990 


PROVIDER CODE 

TOTAL TREATMENT 

TOTAL VALUE 

112 

45 

25.3 

113 

841 

602.6 

114 

525 

356.0 

117 

1085 

759.2 

119 

756 

436.7 

126 

532 

349,9 

131 

1127 

811.8 

132 

351 

182.8 

133 

210 

1098.0 

425 

793 

599.5 


CUMULATIVE TOTALS: 6265 5221.8 
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PAGE 


1 


MAJOR TREATMENT REPORT 
FOR THE MONTH OF JUNE 


PROVIDER TREATMENT CODES / WEIGHTED VALUES 



0001 

0002 

9918 

9923 

9972 

112 

1/ 

2.0 

0/ 

0.0 

0/ 

0.0 

0/ 

0.0 

7/ 5.6 

113 

0/ 

0.0 

0/ 

0.0 

9/ 

4.5 

14/ 

11.2 

114/ 91.2 

114 

0/ 

0.0 

0/ 

0.0 

5/ 

2.5 

4/ 

3.2 

60/ 48.0 

117 

0/ 

0.0 

0/ 

0.0 

5/ 

2.5 

9/ 

7.2 

87/ 69.6 

119 

0/ 

0.0 

0/ 

0.0 

3/ 

1.5 

9/ 

7.2 

31/ 24.8 

126 

1/ 

2.0 

0/ 

0.0 

4/ 

2.0 

0/ 

0.0 

29/ 23.2 

131 

0/ 

0.0 

0/ 

0.0 

0/ 

0.0 

0/ 

0.0 

113/ 90.4 

132 

0/ 

0.0 

0/ 

0.0 

0/ 

0.0 

0/ 

0.0 

148/118.4 

133 

34/ 

68.0 

7/ 

28.0 

0/ 

0.0 

0/ 

0.0 

0/ 0.0 

425 

0/ 

0.0 

0/ 

0.0 

17/ 

8.5 

0/ 

0.0 

0/ 0.0 
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APPENDIX I 


NAVMED FORM 6600/11 


The docvament presented on the following two pages is an 
excerpt from NAVMEDCOMINST 6600 IB 
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navmbd form 6finn/fi 


The document presented on the following 
from NAVMEDCOMINST 6600.IB 


page 


is 


an excerpt 
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SECTION I. INTRODUCTION 


1. PURPOSE OF THE USER'S MANUAL 

The purpose of this User's Guide is to provide 
guidelines for personnel using this Dental Information 
Retrieval System (DIRS) program. This user's manual should 
answer most questions concerning the operation of DIRS. 
Please take time to read this manual carefully. Reading the 
manual before installation may save you a lot of frustration 
and time later on. 

2. PROJECT REFERENCES 

This guide is divided into sections, depending on the 
operation being performed. Material is presented in a step 
by step fashion. It is designed to provide timely reference 
to aid in resolving most problems that may occur while using 
DIRS. 

3. SECURITY AND PRIVACY 

The DIRS system's databases are unclassified; therefore 
no security clearance is required to gain access. However, 
be informed that each command must have an Automatic Data 
Processing Security Plan (ADPSP). It may be advisable to 
secure all spaces that contain Personal Computers (PC). 
Securing PCs also means protecting data from unauthorized 
personnel that could willingly or accidently destroy data 
stored on PC. 

4. SYSTEM OVERVIEW 

The DIRS system is designed to gather accurate 
information in a relatively quick time frame. It will 
replace the slow and tedious manual process of producing the 
monthly DIRS report. The system will also maintain 
production data on dental officers providing dental 
services, and other support staff. The DIRS system is a 
menu-driven data base system prepared as a graduate level 
thesis project by two students at the Naval Postgraduate 
School, Monterey, Ca. DIRS is designed so that even non¬ 
computer personnel should be able to operate the system 
without too much difficulty (reading the user's manual will 
help) . 

5. SYSTEM RESPONSIBILITY 

The Dental Department has custody of the DIRS system 
and will ensure that all files are properly maintained and 
kept current. The use of this system is restricted to 
personnel who are trained on the IBM PCs (or compatibles) in 
accordance with current instructions and those specifically 
authorized in writing by the Head, Dental Department. 
Furthermore, program modification shall be the 
responsibility of custodial command. 
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6. SYSTEM CONFIGURATION 

The DIRS system is simple to use and does not require 
complicated ADP equipment. The system's command files are 
compiled; meaning, dBASE III PLUS does not have to be 
installed on your PC. It is designed to work on any IBM 
compatible PC. Reports are produced using a near-letter 
quality printer, except for the DIRS reports that 
headquarters produce. An OCR scanner is used to read the 
DIRS report after it is printed; therefore, an OCR printhead 
must be used. It is a requirement that the printer will 
accept this type of printhead. The DIRS system will prompt 
the user to switch to the OCR fauxiliary) printer when 
calling the monthly DIRS Report. Remember to switch back to 
your primary printer after completing vour OCR report. 

7. HARDWARE REQUIREMENTS 

a. IBM-PC compatible computer W/640K memory. 

b. 20 megabyte hard disk. 

c. MS-DOS version 3.0 or higher. 

d. An OCR 10 pitch daisy wheel printer. 


SECTION II. SYSTEM INSTALLATION 

1. DIRS INSTALLATION. 

Insert disk #1 in drive A:. From the root directory, 
at the C; drive DOS prompt, type "A;install." The install 
program will prompt the user for a directory name where DIRS 
is to be installed. Enter up to ten characters. The 
install program will create a directory and copy the 
necessary files to that directory. The install program will 
then ask the user to insert floppy #2 in drive a;, please do 
so at that time. When installation is completed, a message 
will appear on screen indicating that installation is 
complete. Notice that you are in the newly created 
directory where DIRS has been installed. 

2. LOADING COMMAND INFORMATION FILE 

To run DIRS, type "DIRS" in the directory where DIRS 
has been installed. Several screens will appear prompting 
the user for vital system and command information. The 
screens presented below are similar to those that the user 
will see. 

As you are operating the program, you will be directed 
by the 'COMMAND NAME' and 'SYSTEM NAME' prompts to enter the 
name of your command and title your DIRS. We recommend that 
you title the system 'DENTAL INFORMATION RETRIEVAL SYSTEM' 
since that is the function of the system. Keep in mind that 
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fields A and B are used to title the upper left corner of 
all the menus presented in DIRS. See Figure (1) for an 
example of screen heading (upper left corner). In a sense, 
you, the user are actually customizing the system to fit 
your personal taste and requirements. Field C is simply a 
prompt requesting the number of clinics that will be 
supported by your command. For example, if you are a branch 
clinic, ship, or a stand-alone independent clinic, enter 
one. On the other hand, a headquarters command which will 
be requesting information from its subordinate clinics 
should enter the number of subordinate clinics and itself as 
the correct number to be supported. 

If an error as been made in the data entered, field D 
will allow the user to reenter the data by entering an 'N' 
(No), in that field. Answering *Y' (Yes), will generate 
another screen prompting you with fields (E-G). Enter your 
command Unit Identification Code (UIC) in Fields E. Note 
that field E will only tolerate numeric values to be 
entered. Leave a space then insert a dash (-) followed by 
another space before entering the official command name. It 
is important that the official command be entered correctly 
since what you input in this field is the exact data to be 
output on several reports generated by DIRS. Fields F&G are 
the UCA codes presently associated with your DIRS reporting 
procedure. Again the system will prompt to see if data is 
correct. Answering 'N' (No) to this prompt will allow 
correction to be made. Note that it does not matter whether 
your data is entered in upper or lower case, DIRS will 
default to upper case. 


(Initial setup screen #1) 

"The following information should only be entered once. 
DIRS will remember the information that you are about 
to enter. If unsure of what you must enter, see the 
user's manual. PLEASE ANSWER THE FOLLOWING:" 

COMMAND NAME: (Field A) 

SYSTEM NAME: (Field B) 


"HOW MANY CLINICS WILL DIRS BE SUPPORTING (1-9):" (Field C) 

"DATA CORRECT (Y/N)?" (Field D) 
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(Initial setup screen #2) 


UCA CODES 
LAB - CLINICAL 

UIC - CLINIC NAME DIRS CODE <0097 - 0096> 

Example: 55555 - PORT NEVERSAIL CCYA CAYA 

ENTER UIC; (Field E) UCA CODE: (Fields F & G) 


•'DATA CORRECT (Y/N)?" (Field D) 


3. COMMAND INFORMATION FILE CORRECTION 

Ok, so you followed all the instructions and still 
managed to enter incorrect information. The main menu is 
displayed and you don't like the system title block. To 
change the information specified in section II, paragraph 2, 
exit DIRS by selecting "QUIT" from the main menu. You 
should now be at the C: prompt in the directory where dirs 
has been installed. Type "DEL COMM.MEM" then type "DIRS." 
The RAM (Random Access Memory file) will be deleted allowing 
you to recreate this RAM resident file as per directions 
stated in section II, paragraph 2. 


4. LOADING ESSENTIAL FILES 

Before any daily input can be entered, provider 
information must be entered. After all, how can one record 
treatment procedures on a provider without a provider? The 
provider file must be completed before any data can be 
entered. It is recommended that a range of valid provider 
codes be assigned to each department or clinic. It is also 
suggested that ranges have some type of meaningful 
relationship to a particular clinic or UIC, i.e.: 100-200 
would be providers from clinic A, 201-300 would be providers 
from clinic B, and so on. Another suggestion is to end the 
provider code with an odd or even configuration. For 
example, 105 would represent a two-week active duty 
reservist. 100 would represent a full-time provider. 

Section III provides instructions on how to add, edit, or 
delete a provider. 

The Dirs treatment database has already been completed 
with the most common codes used. This database may be 
updated if need be, by following the instructions in section 
III. 
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SECTION III. OPERATION PROCEDURES 


1. START-UP PROCEDURES 

The start-up procedure is designed for those with 
absolutely no computer background. Those of you with basic 
"DOS" and PC knowledge may choose to overlook this brief 
paragraph. 

Turn on your computer. Now that your computer is on, 
check to see if your peripheral devices are on (printers, 
power director, display terminal, etc.). When everything is 
turned on, change directories to the directory that contains 
DIRS. This can be achieved by typing "CD\directory name" 
where "directory name" is the name that you ha^^e selected to 
label your directory. Now type "DIRS," this command will 
bring up the main menu or the memory screen discussed in 
Section II, if it has not already been loaded. 

2. OPERATION PROCEDUPiiS 

Using this system is simply a matter of doing what the 
computer tells you to do. Your DIRS system is fully menu 
driven. Menu driven means that you can select any option 
from the menu by simply moving the arrows (ti) until you 
have highlighted your desired selection. You can also 
select an option by pressing the first letter of the desired 
option, but in the event that two menu items start with the 
same letter, the system will default to the first selection. 
The most complicated thing about this system is getting over 
the phobia generally associated with computers. Remember to 
relax and read what the computer is prompting you to do. 
Reading prompts (the messages that the system displays when 
it wants you to do something) is generally the key to 
success when using any menu driven system. 


SECTION IV. MAIN MENU AND SUB MENU. 

The diagram provided on the next page titled; "Menu 
Hierarchy," should provide a helpful overview of the various 
menu screens available in DIRS should you get lost in a 
particular level or just want a ready reference to a 
destination or operation of choice. You may find it helpful 
to enlarge the diagram and post it in a convenient location 
until you gain familiarity with the system. 
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THE MAIN MENU 
Heading 


A 


B 


NAVAL DENTAL CLINIC, USN 13:17:17 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.0 


MAIN MENU 

INPUT DIRS DATA 

CHANGE DIRS CODES 

UPDATE PROVIDER CODES 

QUERIES 

FILE UTILITIES 

HEADQUARTERS ONLY 

QUIT 


USE UP AND DOWN CURSOR KEYS ti TO HIGHLIGHT ITEM AND 
PRESS<RETURN> 


Prompt & Status Box 

Figure 1. Main Menu Screen 


To operate the DIRS system, enter the first letter 
which corresponds to the item in the menu body that you want 
to select, or move the arrow keys (ti) to highlight your 
choice. All menus have a RETURN option to return to the 
calling Menu. Note that the heading section of the menu 
above, displays the command name and system title that you 
have selected and entered at initial installation. The 
upper right corner of the menu displays such information as 
current date, time, and screen number. All menus within 
DIRS support this type of display. The body or middle of 
the screen displays options available. The option may be 
selected as per stated in the bottom section of the screen. 
This bottom section is the area that the user should pay 
particular attention to, since error messages and/or user 
prompts will be displayed there. The system will also beep 
when invalid or incorrect data has been input. 

2. INPUT DIRS DATA 

The first screen that will appear when selecting option 
one (INPUT DIRS DATA) is displayed below (Figure 2). Enter 
"yii (yes) , if the displayed month is the desired month for 
data entry. Enter "N" (no) to select another month. When 
"N" is selected a window will appear displaying options that 
may be keyed in at the prompt (see Figure 3). The default 

month (open month on screen) is the current calendar month 
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month (open month on screen) is the current calendar month 
based on the computers system clock. 


NAVAL DENTAL CLINIC, USN 08:05:14 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.1.1 


OPEN MONTH IS JANUARY 


IS THIS CORRECT? Y/N 

Figure 2. Input DIRS Data (Open Month Confirmation) 


NAVAL DENTAL CLINIC, USN 09:02:20 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.1.1 


JAN 

JUL 

FEB 

AUG 

MAR 

SEP 

APR 

OCT 

MAY 

NOV 

JUN 

DEC 


ENTER THREE LETTERS OF NEW MONTH: 


Figure 3. Month Input Screen 


To select the correct month, the three letter 
abbreviation is entered at the prompt. For example, typing 
JUN in the month selection screen will the month of June for 
data entry. Once the desired month has been opened, the 
provider prompt screen will follow. 

To select a provider, the provider code may be entered 
directly if the code is known, or by pressing the <H0ME> 
key, an additional window with the valid provider codes 
assigned to the reporting command will pop up. From the 
available valid provider codes on screen, the corresponding 
number that matches the desired provider code may be 
entered. (See Figures (4) & (5)). 


121 













NAVAL DENTAL CLINIC, USN 08:18:58 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.1.1 


PROVIDER CODE: 


ENTER PROVIDER CODE OR PRESS <HOME> FOR HELP 


Figure 4. Provider Code Entry Screen 


NAVAL DENTAL CLINIC, USN 
DENTAL INFORMATION RETRIEVAL 

08:18:58 01/13/90 

SYSTEM SCREEN #1.1.1 

PROVIDER CODE 

RANK 

NAME 

1. 

100 

CDR 

NAVY, JOSEPH 

2 . 

200 

LT 

NAVY, SON 

3. 

300 

LT 

MESIAL, DECAY 

4. 

400 

CAPT 

TOOTH, DECAY 

5. 

455 

LT 

RESERVE, DENTIST 

6. 

500 

CDR 

BUCKLE, PIT 

7. 

600 

LT 

LINGUAL, DISTAL 

8. 

700 

ADM 

DENTAL, SERVICE 

PRESS 

NUMBER OF ITEM 

, RETURN 

TO CONTINUE, OR "Q” TO QUIT 


Figure 5. Provider Codes Screen 


To select a valid provider, enter the matching number 
in the leftmost column, i.e.: entering number "1" would 
select provider 100; CDR Navy. The provider code may also 
be entered directly on the provider input screen. This 
method of provider data entry provides a method to check the 
provider code file to validate a correct provider code for 
the reporting unit. Entering an erroneous code (a code not 
currently in the provider code file) results in an error 
message indicating that fact, and further prompts the user 
to enter another code. When the provider field is correctly 
entered, the screen displayed in Figure 6 will follow, 
prompting the user to enter a valid treatment code. As 
previously discussed, to escape the DIRS entry routine, 
press <RETURN> at a blank DIRS field. The "ESC" key provides 
another escape route by allowing the user to select the 
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another escape route by allowing the user to select the 
cancel option that will pop-up in the upper left corner of 
the screen. This escape feature will return the user 
completely back to the DOS C: prompt. 


NAVAL DENTAL CLINIC, USN 08:05:14 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.1.2 


Entering Data for Provider: CDR JOSEPH NAVY CODE: 100 


PRESS THE <H0ME> KEY FOR A LIST OF DIRS CODES TO 
SELECT FROM. 

PRESS <RETURN> ON AN EMPTY FIELD TO RETURN TO THE 
MAIN MENU. 


ENTER DIRS CODE: 


Figure 6. DIRS Treatment Code Entry Screen 

Pressing the <H0ME> key will display all valid DIRS codes 
such as presented in Figure 7. 


NAVAL DENTAL CLINIC, USN 08:05:14 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.1.2 


DIRS 

CODE 

DESCRIPTION 

WEIGHT 

1. 

0001 

POUR CAST 

2.0 

2. 

0002 

POUR CAST, FX 

4.0 

3 . 

0003 

BOX AND POUR 

5.0 

4 . 

0004 

IMP TRAY CUS 

4.0 

5. 

0005 

POUR ALT CAS 

5.0 

6. 

0006 

ARTIC. SIMPL 

1.0 

7. 

0007 

ARTIC. SEMI 

1.5 

8. 

0008 

ARTIC. FULL 

2.0 

9. 

0009 

SOLDER/PER AREA 

4.0 


PRESS NUMBER OF ITEM, RETURN TO CONTINUE, OR "Q” TO QUIT 
Figure 7. DIRS Treatment Codes 
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The DIRS treatment code may also be entered directly on 
the DIRS prompt screen or the <HOME> key may be used to 
assist the user in the event that the correct DIRS code is 
unknown. This help function is not a mandatory input 
procedure, if you know the correct code, entering it 
directly will save time. 

To select a DIRS treatment code, the corresponding 
number displayed in the leftmost column is selected by 
typing the appropriate number . Pressing the <Page 

Down> or <Page Up> keys will scroll through the list to 
display other treatment codes. 

After a valid provider and treatment code have been 
selected the following screen (Figure 8) will appear: 


NAVAL DENTAL CLINIC 

, USN 

12:04:39 

01/13/90 

DENTAL INFORMATION 

RETRIEVAL SYSTEM 

SCREEN # 

1.1.3 

Entering Data for 

Provider: TEST 

TEST TEST 

CODE: 100 

DIRS Code: 0120 

Additions 

Totals 

Year 

Beneficiaries 

to File 

in File 

to Date 

Category 1 

0 

0 

0 

Category 2 

0 

0 

0 

Category 5 

0 

0 

0 

Category 8 

0 

0 

0 

Category 9 

0 

0 

0 

Category 10 

0 

0 

0 

Category 11 

0 

0 

0 

Category 12 

0 

0 

0 

Category 13 

0 

0 

0 

ENTER NEW VALUES 

AND PRESS RETURN 




Figure 8. DIRS Data Entry Screen 


Data entry for an individual provider is accomplished 
using screen 1.1.3, (depicted in Figure 8) by entering the 
correct quantity of procedures completed in each dental 
beneficiary category. A listing with a brief definition of 
each beneficiary category code is provided in the diagram on 
the next page. 

The <RETURN> key is used to move the cursor to the next 
field for data entry. The steps listed above are repeated 
until the user has completed data entry for a particular 
provider. Data entry error corrections are accomplished in 
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BENEFICIARY CODES: 

01 - Active Duty, U.S. Navy 

02 - Active Duty, U.S. Marine Corps 

06 - Active Duty, Other Services 

08 - Recruit, U.S. Navy or Marine Corps 

Od - Dependents of Active Duty 

U.S. Uniformed Services Personnel 

10 - Dependents of Retired or Deceased 

U.S. Unifcrmed Services Personnel 

11 - Retired Uniformed Services Personnel 

12 - Other Personnel not listed In Codes 

01 through 11 and 13 

13 - Dependent Children, 

(17 & under and unmarried) 


a number of ways. The user is prompted with the folowing 
query at the bottom of screen 1.1.3; ”Is this data correct? 
Y/N”. A negative response indicated by typing the "N" key, 
will allow the user to reenter the correct data. The user 
may overwrite the data displayed on screen by moving the 
cursor using the arrow keys to the correct field and 
reentering the correct quantity. Deletion and editing of 
values previously entered for a particular month is 
accomplished by selecting the desired month, provider, and 
treatment, and entering an appropriate negative value to 
either cancel or modify the monthly total for the selected 
record. 

To return to the main menu, the <RETURN> key is pressed with 
the cursor on a blank DIRS input field or typing "Q" when 
prompted from the help screen. 

When a month and provider have been selected, the user 
may continue adding new treatment data without returning to 
the main menu for each instance. To enter data for another 
provider, the user must return to the main menu and select 
the desired month and treatments. The system will default 
to the month of last data entry. Upon termination of a data 
entry session, a final query will prompt the user with the 
following message; "Do you wish to save this data? Y/N." 
Selecting "N" will not save the data entered during the 
session. This particular feature provides a control 
mechanism, allowing the user to correct or terminate a data 
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entry session without arbitrary input of inadequately 
screened or inaccurate data to the database. Selecting "Y" 
will automatically result in appropriate updates to the 
Daily, Monthly, and Yearly files. Selection of "Y" will 
also result in the display of the following messages in the 
status box located at the bottom of the screen; "Adding to 
Monthly Total" and "Adding to Yearly Total," informing the 
system user of action in progress. 

3. Change DIRS Codes 

Selection 2 from the main menu should be selected when 
you wish to add, delete, edit, or list your DIRS (treatment) 
codes (Figure 9). Deleting means erasing of an existing 
code. Editing means changing an existing code. Please note 
that though some of the most common DIRS treatment codes 
have already been entered, this does not mean that all the 
codes that your clinic uses have been entered. When calling 
these functions, the system works in the same manner as the 
DIRS entry section except that a month does not have to be 
opened. 


NAVAL DENTAL CLINIC, USN 12:47:51 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.2 


DIRS CODES MENU 

ADD CODE 
EDIT CODE 
DELETE CODE 
LIST CODES 
RETURN TO MAIN MENU 


USE UP AND DOWN CURSOR KEYS t i TO HIGHLIGHT ITEM AND 
PRESS<RETURN> 


Figure 9. Change DIRS Codes Menu 


4. Update Provider Codes 

The function of the Update Provider Codes menu (Figure 
10) is similar to that described above for Change DIRS 
Codes. In this instance, rather than the treatment codes, 
the update function and display function pertains to the 
provider at a given command. Again, the command listing of 
providers is provided as a convenience to the system user. 
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NAVAL DENTAL CLINIC, LONG BEACH, CA. 12:47:51 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.3 


PROVIDERS CODE MENU 
ADD CODE 
EDIT CODE 
DELETE CODE 
LIST CODES 
RETURN TO MAIN MENU 


USE UP AND DOWN CURSOR KEYS ti TO HIGHLIGHT ITEM AND 
PRESS<RETURN> 


Figure 10. Update Provider Codes Menu 


NAVAL DENTAL CLINIC, USN 
DENTAL INFORMATION RETRIEVAL 

SYSTEM 

3:18:52 11/10/89 

SCREEN # 1.3.2 

PROVIDER CODE: 

100 



LAST NAME: 

NAVY 



FIRST NAME: 

NAVY 



RANK; 

CDR 

STATUS: 

0 



ENTER 

(R) = Reserve 




(C) = Contract 




(0) = Other <Return> 

ENTER CORRECT PROVIUEP 

INFORMATION 



Figure 11. Provider Code Data Entry Screen 


Note the upper left corner of Figure 11. The screen 
number is now SCREEN #1.3.2. The two means that you are now 
in the edit module under option three (UPDATE PROVIDER 
CODES). All screen within this system provide such 
information. Figure 11 shows a prompt labelled "status." 

You can enter one of three things here as stated on the 
screen. When entering "R" you are telling the system that 
the provider is a reservist. "C" implies that the provider 
is contracted personnel and "O" is all other personnel. 
Whether selecting add, edit, or delete, the screen depicted 
in Figure 12 will be used. 
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5. 


Report. Menu 

The Report menu (Figure 12) presents the user with a 
number of options related to reporting of DIRS data by 
various chronological periods. Using the options available 
in this menu, the current total of treatments, treatments by 
provider, by command, etc. may be obtained. For example, 
the DAILY REPORT will repeat all information keyed-in via 
the "INPUT DIRS DATA" selection. Also note that you will be 
asked whether or not you would like a daily report every 
time you exit the system. Naturally, if no data has been 
entered for that day no report will be generated. 

Additionally, a Major Treatment Report option is 
available as a menu selection for internal reporting 
purposes. Please note that the major report will query on 
up to ten user defined treatment code. Please note: you 
must either change the printer font size (pitch) to 17 
pitch, or use wide printer paper for the report to fit with 
seven or more treatments. The system will forewarn you in 
the event that wider paper is required. 


NAVAL DENTAL CLINIC, LONG BEACH, CA. 12:49:38 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.4 


REPORT MENU 

DAILY REPORT 
MONTHLY REPORT 
ANNUAL REPORT 
PROVIDERS STATS. 

MAJOR TREATMENT REPORT 

RETURN TO MAIN MENU 


USE UP AND DOWN CURSOR KEYS T1 TO HIGHLIGHT ITEM AND 
PRESS<RETURN> 


Figure 12. Branch Clinic Report Menu 


6. File Utilities Menu 

The menu screen presented in Figure 13 offers the 
system user the ability to reindex, backup, transfer, and 
start a new recording year all from within the DIRS 
application. Providing these necessary functions from 
within the system as menu-driven options helps simplify the 
normally onerous and often neglected tasks such as backing 
up the system data. 
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NAVAL DENTAL CLINIC, LONG BEACH, CA. 13:50:16 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.5 


FILE UTILITIES 

REINDEX DATA FILES 
BACKUP DATA FILES 
START NEW YEAR 
TRANSFER DATA TO DISK 
RETURN TO MAIN MENU 


USE UP AND DOWN CURSOR KEYS ti TO HIGHLIGHT ITEM AND 
PRESS<RETURN> 


Figure 13. File Utilities Menu 


The reindex data files option should be selected when 
the system shows signs of incorrect operation such as 
incorrectly assigned totals or data. As an example, reports 
may display zero work for all providers at a specified 
command for a given month. If this information is 
incorrect, using the reindex option will reassign the 
appropriate key field to their respective records. The 
reindex feature is often required in any database system. 
Power surges, improper file closing and hardware 
malfunctions are examples of possible causal factors for 
’udex distortion. The reindex option is provided to 
reestablish the proper links and pointers to correct the 
potential damage caused by these malfunctions. 

Selecting the backup data files option will store all 
data on floppy disks. Be aware that your diskette must be 
formatted before any data can be captured on disk. See your 
DOS manual on formatting floppies. It is strongly 
recoirmended that backups be made at least once per week. 
Remember PCs are mechanical in nature. Should your PC 
breakdown, having a current backup will save you many hours, 
if not days, of data reentry. 

The "Start New Year" option is provided when the users 
wish to begin recordkeeping functions for a new reporting 
year; either calendar, fiscal or other arbitrary selection. 
Failure to select this option when starting a new reporting 
period will result in overwritten data values and incorrect 
totals for the selected period. 

The "Transfer Data to Disk" option is selected to 
transfer data for a monthly reporting period to a "floppy 
disk" for subsequent export to the appropriate Headquarters 
command. Production of the OCR report form may only be 
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accomplished at the Headquarters level after import of the 
transfer files. 

The transfer routine will transfer the working file to 
a floppy disk. The UIC window located in the lower right 
corner depicted in Figure 14, prompts the user to select a 
number; 1 through 5. The number ''5'' is representative of a 
Headquarters command with five subordinate DTFs. This 
number will reflect the actual number of DTFs supporting as 
few as one or as many as nine. If the system is being used 
at a branch clinic, only one UIC is displayed and selected. 
User input of the correct UIC is critical, because a UIC 
FIELD will be appended on the TRANS. FILE based on the UIC 
input. The TRANS. FILE is the database export file to be 
received by the corresponding Headquarters command. This 
routine will be selected when a subordinate DTF is recjuired 
to submit data to headquarters. Regardless of transmission 
medium, the export routine must be selected to transfer all 
data to floppy disk, prior to submission of the updated 
monthly data requirements. The export procedure described 
above provides a necessary if subtle control mechanism 
ensuring that data back-ups are performed at least once a 
month. When properly labeled with the appropriate UIC, and 
month of transfer, the floppy disks containing the TRANS 
database file (dbf) provide a convenient source of back-up 
data. The menu status box (part C) will provide a prompt to 
insert a floppy disk into the appropriate drive, and a 
message indicating the number of records transferred. 


NAVAL DENTAL CLINIC, USN 13:51:59 11/10/89 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.5.4 


ENTER UIC: 

ENTER MONTH OF REPORT: 

i.e. : 


1) 

*** VALID UIC *** 

00000 - HQ & NOWHERE 

2) 

55555 

- PORT NEVERSAIL 

3) 

55511 

- POINT HERE 

4) 

51515 

- CHINA 

5) 

99999 

-CO BEACH 

0) 

RETURN 

TO MAIN MENU 

SELECT (0 

- 5) ? 0 


Figure 14. File Transfer Screen 
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7. 


Headquairters Menu 

The Headquarters menu (Figure 15) is intended for the 
Headquarters command to facilitate the transfer of DIRS data 
from subordinate dental commands, and the obligatory 
submission of DIRS reports. To that end, file import/export 
facilities are provided as menu options tor operation from 
within the DIRS application. 


NAVAL DENTAL CLINIC, LONG BEACH, CA. 13:53:44 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.6 


HEADQUARTER'S MENU 

IMPORT FILES 
EXPORT FILES 
DO REPORTS 

START NEW YEAR (KQ ONLY) 
RETURN TO MAIN MENU 


USE UP AND DOWN CURSOR KEYS ti TO HIGHLIGHT ITEM AND 
PRESS<RETURN> 


Figure 15. Headquarter's Menu 


7.1. IMPORT FILES. 

The "IMPORT FILES" option is provided to receive files 
transmitted from subordinate commands. 

7.2. EXPORT FILES. 

Similarly, the "EXPORT FILES" option is provided to 
allow a Headquarters command to send a pre-selected month of 
data for all of its subordinate commands. 

7.3. DO REPORTS. 

Selection of the "DO REPORTS" option will result in 
the display of the screen presented in Figure 16 with 
provisions for selection of either the DIRS OCR format 
monthly report or a "PROVIDERS STATS." internal report 
option. 
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NAVAL DENTAL CLINIC, LONG BEACH, CA. 13:53:44 01/13/90 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1,6.2 


HEADQUARTER'S REPORTS 

MONTHLY DIRS REPORT 
PROVIDER STATS. 

RETURN TO MAIN MENU 


USE UP AND DOWN CURSOR KEYS ti TO HIGHLIGHT ITEM AND 
PRESS<RETURN> 


Figure 16. Headquarters Reports 


A. MONTHLY DIRS REPORT 

The "MONTHLY DIRS REPORT" selection option is supported 
by the menu screen presented in Figure 17. This selection 
will enable the Headquarters to print the standard monthly 
NAVMED 6600/8 OCR form required for submission of DIRS data 
to COMNAVMEDCOM using an OCR font capable printer. 


NAVAL DENTAL CLINIC, LONG BEACH, CA. 11:50:26 11/10/89 

DENTAL INFORMATION RETRIEVAL SYSTEM SCREEN # 1.5.1 


SELECT UIC: 00000 


Name of Facility: SEE TABLE 1 


Provider's Hours: 

12.00 


*** VALID UIC *** 




1) 

00000 - HQ & LB CLINIC 



— 

2) 

55555 - PORT NEVERSAIL 

(1) 

Original 

1 

3) 

55544 - POINT HERE 

(2) 

Correction 

1 Select 

4) 

51515 - CHINA 

(3) 

resubmission 

1 (1-3)? 

5) 

99999 -CO BEACH 




0) 

RETURN TO MAIN MENU 




SELECT (0-5)? 1 


IS DATA CORRECT (Y/N)? 
Figure 17. HQ OCR DIRS SCREEN 
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The first step in running this procedure is selecting a 
UIC which represents the reporting branch clinic. Step 
number 2 is to enter the facility's name. Step 3 is the 
provider's hour field from your monthly MEPRS report. Step 
4 is a selection representing the status of the report. An 
original report is the first submission for the reporting 
period. A correction is a submission to add, delete or 
correct data detected locally or by the OCR reader. Since 
corrected reports are not supposed to duplicate data, the 
corrected reports will have to be typed manually. Corrected 
reports consist of applicable changes only; (i.e., additions 
or deletions for specific treatment codes). A resubmission 
is the forwarding of one, several, or all pages to MEDCOM- 
633 that were not read by OCR reader. A resubmission does 
not have to performed manually. The last step is a 
validation field asking you to enter a "Y" (yes) or "N" (no) 
if the data is correct. Should you enter a no, you will be 
asked to select a UIC, or if you so desire at this time exit 
this routine. When lining up the DIRS form in the OCR 
printer, a lot of trial and error may be necessary at first 
to line up the form exactly. Once lined up, it is highly 
recommended that you mark your printer so that next time you 
will know exactly where to line up the form. The ideal 
line-up is identified when an "L" is typed right on top of 
the OCR FORM "L." 

B. PROVIDER STATS. 

The Provider Stats option at the Headquarters level is 
a compilation of all subordinate DTF's Provider Stats 
reports. This routine is identical to the routine described 
for individual providers' stats. The only exception is that 
this report reflects the entire command. An example of the 
Provider Stats Report is provided in Appendix K. 

C. START NEW YEAR (HQ ONLY). 

The "START NEW YEAR (HQ ONLY)" option provided on the 
Headcjuarters menu is identical in function to that provided 
by the "START NEW YEAR" option for subordinate DTFs except 
that it only reinitializes the headquarter's database. As 
previously discussed, this option is used to initialize 
records to zero, providing recordkeeping functions for a new 
reporting year; either calendar, fiscal or other arbitrary 
selection. 


8. QUIT. 

As you probably have figured out the "Q" (QUIT) option 
exits your system and returns you to the DOS prompt. 
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